一、ARP技術概念介紹

為什么講ARP技術，因為平常工作中有接觸。還有就是LVS的dr模式是用到arp的技術和數據。

1、什么是ARP協議

ARP協議全程地址解析協議（AddressResolution Protocol，ARP）是在僅知道主機的IP地址時確定其物理地址的一種協議。因IPv4和以太網的廣泛應用，其主要作用是通過已知IP地址，獲取對應物理地址的一種協議。

2、什么是ARP代理（ARP proxy）

在網絡中代理是非常常見的，所謂的代理就是我朝一個人要，另外一個人給。生活中一個比較實際的例子就是，房屋中介。

Arp協議要求通信的主機的雙方必須是在物理的同一個網段。那如果發送主機和目標主機不是在同一個局域網里，而ARP廣播包是不能夠跨越網段進行傳輸的。所以此時就需要一個路由或ARP中繼技術來轉發ARP請求包。客戶端獲取到的MAC地址是路由器或者中繼的MAC地址。那么之后這個客戶端發給目的端的數據，都會先發給這個路由器或ARP中繼，再進而轉給目的端，這種情況就稱為ARP代理。

3、arp協議工作原理

原理圖：

當主機10.0.0.1要發送數據給10.0.0.2數據，會首先去查本地的arp緩存表，如果有此IP地址和此主機對應的MAC地址，如果有就可以直接傳輸數據。如果沒有就主機10.0.0.1就會向局域網去廣播，詢問誰的IP地址是10.0.0.2.此時在本局域網中的所有主機都能夠收到此廣播包，但只有主機10.0.0.2才會回應這個廣播包。會以單播的形式直接回復10.0.0.2說我的MAC地址為多少。此時10.0.0.1收到了此信息，那么兩者之間就能夠通過MAC地址進行通信了。并且將這個ARP和IP對應信息緩存到ARP緩存表里。

ARP欺騙工作原理：

ARP欺騙就是通過偽造IP地址和MAC地址對實現ARP欺騙的，它能夠在網絡中產生大量的ARP包，來讓網絡堵塞。攻擊主機只要持續的發送假的ARP包，讓網絡中的主機緩存錯誤的IP-MAC對應信心，造成網絡中斷或中間人攻擊。

ARP攻擊主要是在局域網中的，因為ARP包是不會垮網絡傳播的。所以劃分VLAN能夠減少當受到ARP攻擊后，網絡受影響的范圍。

ARP欺騙過程圖及講解：

ARP欺騙防御辦法

1）進行MAC和IP地址進行綁定

2）殺毒軟件開啟arp防火墻

ARP病毒排查

1）使用arp –a命令查看本地arp緩存表，查看重復MAC地址或在交換機路由器上查看重復MAC地址。

2）使用ARP防御軟件或檢測軟件（如：科萊，彩影arp防火墻分析流量，查找可以攻擊源）

3）使用折半法排除網絡出錯范圍。（如先斷開一般的網絡查看是否正常，如果正常就說明斷開的那部分有問題。然后再接上剩下的那一半繼續查看，依次類推最終找到問題點）

當然排查、預防ARP攻擊的方法有很多，大家可以自己尋找。

------------------------------自我后續小結--------------------------------------

ARP協議的功能就是能夠通過IP地址解析到MAC地址。而ARP欺騙的手段就是通過偽造IP-MAC信息，讓網絡上的主機受騙。誤以為攻擊主機就是他們要發送的目標主機（路由器）這樣就將信息都發給了攻擊者，攻擊者就能獲取網絡其他主機的數據包。而且網絡上的主機會出現網絡中斷等現象。如果攻擊者在網絡上大量的發送ARP信息，也會造成網絡的堵塞。

---------------------------------------------------------------------------------

一、集群簡介

什么是集群

計算機集群簡稱集群是一種計算機系統，它通過一組松散集成的計算機軟件和/或硬件連接起來高度緊密地協作完成計算工作。在某種意義上，他們可以被看作是一臺計算機。集群系統中的單個計算機通常稱為節點，通常通過局域網連接，但也有其它的可能連接方式。集群計算機通常用來改進單個計算機的計算速度和/或可靠性。一般情況下集群計算機比單個計算機，比如工作站或超級計算機性能價格比要高得多。

集群就是一組獨立的計算機，通過網絡連接組合成一個組合來共同完一個任務

LVS在企業架構中的位置：

以上的架構只是眾多企業里面的一種而已。綠色的線就是用戶訪問請求的數據流向。用戶-->LVS負載均衡服務器--->apahce服務器--->mysql服務器&memcache服務器&共享存儲服務器。并且我們的mysql、共享存儲也能夠使用LVS再進行負載均衡。

---------------小結-------------------------

集群：就是一組相互獨立的計算機，通過高速的網絡組成一個計算機系統，每個集群節點都是運行其自己進程的一個獨立服務器。對網絡用戶來講，網站后端就是一個單一的系統，協同起來向用戶提供系統資源，系統服務。

-------------------------------------------

為什么要使用集群

集群的特點

1）高性能performance。一些需要很強的運算處理能力比如天氣預報，核試驗等。這就不是幾臺計算機能夠搞定的。這需要上千臺一起來完成這個工作的。

2）價格有效性

通常一套系統集群架構，只需要幾臺或數十臺服務器主機即可，與動則上百王的專用超級計算機具有更高的性價比。

3）可伸縮性

當服務器負載壓力增長的時候，系統能夠擴展來滿足需求，且不降低服務質量。

4）高可用性

盡管部分硬件和軟件發生故障，整個系統的服務必須是7*24小時運行的。

集群的優勢

1）透明性

如果一部分服務器宕機了業務不受影響，一般耦合度沒有那么高，依賴關系沒有那么高。比如NFS服務器宕機了其他就掛載不了了，這樣依賴性太強。

2）高性能

訪問量增加，能夠輕松擴展。

3）可管理性

整個系統可能在物理上很大，但很容易管理。

4）可編程性

在集群系統上，容易開發應用程序，門戶網站會要求這個。

集群分類及不同分類的特點

計算機集群架構按照功能和結構一般分成以下幾類：

1）負載均衡集群（Loadbalancingclusters）簡稱LBC

2）高可用性集群（High-availabilityclusters）簡稱HAC

3）高性能計算集群（High-perfomanceclusters）簡稱HPC

4）網格計算（Gridcomputing）

網絡上面一般認為是有三個，負載均衡和高可用集群式我們互聯網行業常用的集群架構。

（1）負載均衡集群

負載均衡集群為企業提供了更為實用，性價比更高的系統架構解決方案。負載均衡集群把很多客戶集中訪問的請求負載壓力可能盡可能平均的分攤到計算機集群中處理。客戶請求負載通常包括應用程度處理負載和網絡流量負載。這樣的系統非常適合向使用同一組應用程序為大量用戶提供服務。每個節點都可以承擔一定的訪問請求負載壓力，并且可以實現訪問請求在各節點之間動態分配，以實現負載均衡。

負載均衡運行時，一般通過一個或多個前端負載均衡器將客戶訪問請求分發到后端一組服務器上，從而達到整個系統的高性能和高可用性。這樣計算機集群有時也被稱為服務器群。一般高可用性集群和負載均衡集群會使用類似的技術，或同時具有高可用性與負載均衡的特點。

負載均衡集群的作用

1）分擔訪問流量（負載均衡）

2）保持業務的連續性（高可用）

（2）高可用性集群

一般是指當集群中的任意一個節點失效的情況下，節點上的所有任務自動轉移到其他正常的節點上，并且此過程不影響整個集群的運行，不影響業務的提供。

類似是集群中運行著兩個或兩個以上的一樣的節點，當某個主節點出現故障的時候，那么其他作為從 節點的節點就會接替主節點上面的任務。從節點可以接管主節點的資源（IP地址，架構身份等），此時用戶不會發現提供服務的對象從主節點轉移到從節點。

高可用性集群的作用：當一個機器宕機另一臺進行接管。比較常用的高可用集群開源軟件有：keepalive，heardbeat。

（3）高性能計算集群

高性能計算集群采用將計算任務分配到集群的不同計算節點兒提高計算能力，因而主要應用在科學計算領域。比較流行的HPC采用Linux操作系統和其它一些免費軟件來完成并行運算。這一集群配置通常被稱為Beowulf集群。這類集群通常運行特定的程序以發揮HPCcluster的并行能力。這類程序一般應用特定的運行庫, 比如專為科學計算設計的MPI庫。

HPC集群特別適合于在計算中各計算節點之間發生大量數據通訊的計算作業，比如一個節點的中間結果或影響到其它節點計算結果的情況。

常用集群軟硬件

常用開源集群軟件有：lvs，keepalived，haproxy，nginx，apache，heartbeat

常用商業集群硬件有：F5,Netscaler，Radware，A10等

二、LVS負載均衡集群介紹

負載均衡集群的作用：提供一種廉價、有效、透明的方法，來擴展網絡設備和服務器的負載帶寬、增加吞吐量，加強網絡數據處理能力、提高網絡的靈活性和可用性。

1）把單臺計算機無法承受的大規模的并發訪問或數據流量分擔到多臺節點設備上分別處理，減少用戶等待響應的時間，提升用戶體驗。

2）單個重負載的運算分擔到多臺節點設備上做并行處理，每個節點設備處理結束后，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。

3）7*24小時的服務保證，任意一個或多個設備節點設備宕機，不能影響到業務。在負載均衡集群中，所有計算機節點都應該提供相同的服務，集群負載均衡獲取所有對該服務的如站請求。

LVS介紹

LVS是linux virtual server的簡寫linux虛擬服務器，是一個虛擬的服務器集群系統，可以再unix/linux平臺下實現負載均衡集群功能。該項目在1998年5月由章文嵩博士組織成立。

以下是LVS官網提供的4篇文章：（非常詳細，我覺得有興趣還是看官方文檔比較正宗吧！！）

http://www.linuxvirtualserver.org/zh/lvs1.html

http://www.linuxvirtualserver.org/zh/lvs2.html

http://www.linuxvirtualserver.org/zh/lvs3.html

http://www.linuxvirtualserver.org/zh/lvs4.html

IPVS發展史

早在2.2內核時，IPVS就已經以內核補丁的形式出現。

從2.4.23版本開始ipvs軟件就是合并到linux內核的常用版本的內核補丁的集合。

從2.4.24以后IPVS已經成為linux官方標準內核的一部分

從上圖可以看出lpvs是工作在內核層，我們不能夠直接操作ipvs，vs負載均衡調度技術是在linux內核中實現的。因此，被稱之為linux虛擬服務器。我們使用該軟件配置lvs的時候，不能直接配置內核中的ipvs，而需要使用ipvs的管理工具ipvsadm進行管理。通過keepalived也可以管理LVS。

LVS體系結構與工作原理簡單描述

LVS集群負載均衡器接受服務的所有入展客戶端的請求，然后根據調度算法決定哪個集群節點來處理回復客戶端的請求。

LVS虛擬服務器的體系如下圖所示，一組服務器通過高速的局域網或者地理分布的廣域網相互連接，在這組服務器之前有一個負載調度器（load balance）。負載調度器負責將客戶的請求調度到真實服務器上。這樣這組服務器集群的結構對用戶來說就是透明的。客戶訪問集群系統就如只是訪問一臺高性能，高可用的服務器一樣。客戶程序不受服務器集群的影響，不做任何修改。

就比如說：我們去飯店吃飯點菜，客戶只要跟服務員點菜就行。并不需要知道具體他們是怎么分配工作的，所以他們內部對于我們來說是透明的。此時這個服務員就會按照一定的規則把他手上的活，分配到其他人員上去。這個服務員就是負載均衡器（LB）而后面這些真正做事的就是服務器集群。

底下是官網提供的結構圖：

LVS的基本工作過程

客戶請發送向負載均衡服務器發送請求。負載均衡器接受客戶的請求，然后先是根據LVS的調度算法（8種）來決定要將這個請求發送給哪個節點服務器。然后依據自己的工作模式（3種）來看應該如何把這些客戶的請求如何發送給節點服務器，節點服務器又應該如何來把響應數據包發回給客戶端。

恩，那這樣我們就只要接下來搞懂LVS的3中工作模式，8種調度算法就可以了。

LVS的三種工作模式：

1）VS/NAT模式（Network address translation）

2）VS/TUN模式（tunneling）

3）DR模式（Direct routing）

1、NAT模式-網絡地址轉換

Virtualserver via Network address translation(VS/NAT)

這個是通過網絡地址轉換的方法來實現調度的。首先調度器(LB)接收到客戶的請求數據包時（請求的目的IP為VIP），根據調度算法決定將請求發送給哪個后端的真實服務器（RS）。然后調度就把客戶端發送的請求數據包的目標IP地址及端口改成后端真實服務器的IP地址（RIP）,這樣真實服務器（RS）就能夠接收到客戶的請求數據包了。真實服務器響應完請求后，查看默認路由（NAT模式下我們需要把RS的默認路由設置為LB服務器。）把響應后的數據包發送給LB,LB再接收到響應包后，把包的源地址改成虛擬地址（VIP）然后發送回給客戶端。

調度過程IP包詳細圖：

原理圖簡述：

1)客戶端請求數據，目標IP為VIP

2)請求數據到達LB服務器，LB根據調度算法將目的地址修改為RIP地址及對應端口（此RIP地址是根據調度算法得出的。）并在連接HASH表中記錄下這個連接。

3)數據包從LB服務器到達RS服務器webserver，然后webserver進行響應。Webserver的網關必須是LB，然后將數據返回給LB服務器。

4)收到RS的返回后的數據，根據連接HASH表修改源地址VIP&目標地址CIP，及對應端口80.然后數據就從LB出發到達客戶端。

5)客戶端收到的就只能看到VIP\DIP信息。

NAT模式優缺點：

1、NAT技術將請求的報文和響應的報文都需要通過LB進行地址改寫，因此網站訪問量比較大的時候LB負載均衡調度器有比較大的瓶頸，一般要求最多之能10-20臺節點

2、只需要在LB上配置一個公網IP地址就可以了。

3、每臺內部的節點服務器的網關地址必須是調度器LB的內網地址。

4、NAT模式支持對IP地址和端口進行轉換。即用戶請求的端口和真實服務器的端口可以不一致。

2、TUN模式

virtual server via ip tunneling模式:采用NAT模式時，由于請求和響應的報文必須通過調度器地址重寫，當客戶請求越來越多時，調度器處理能力將成為瓶頸。為了解決這個問題，調度器把請求的報文通過IP隧道轉發到真實的服務器。真實的服務器將響應處理后的數據直接返回給客戶端。這樣調度器就只處理請求入站報文，由于一般網絡服務應答數據比請求報文大很多，采用VS/TUN模式后，集群系統的最大吞吐量可以提高10倍。

VS/TUN的工作流程圖如下所示，它和NAT模式不同的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel里面，然后發送給RS節點服務器，節點服務器接收到之后解開IP tunnel后，進行響應處理。并且直接把包通過自己的外網地址發送給客戶不用經過LB服務器。

Tunnel原理流程圖:

原理圖過程簡述：

1）客戶請求數據包，目標地址VIP發送到LB上。

2）LB接收到客戶請求包，進行IP Tunnel封裝。即在原有的包頭加上IP Tunnel的包頭。然后發送出去。

3）RS節點服務器根據IP Tunnel包頭信息（此時就又一種邏輯上的隱形隧道，只有LB和RS之間懂）收到請求包，然后解開IP Tunnel包頭信息，得到客戶的請求包并進行響應處理。

4）響應處理完畢之后，RS服務器使用自己的出公網的線路，將這個響應數據包發送給客戶端。源IP地址還是VIP地址。（RS節點服務器需要在本地回環接口配置VIP，后續會講）

3、DR模式（直接路由模式）

Virtual server via direct routing (vs/dr)

DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實服務器的，而真實服務器響應后的處理結果直接返回給客戶端用戶。同TUN模式一樣，DR模式可以極大的提高集群系統的伸縮性。而且DR模式沒有IP隧道的開銷，對集群中的真實服務器也沒有必要必須支持IP隧道協議的要求。但是要求調度器LB與真實服務器RS都有一塊網卡連接到同一物理網段上，必須在同一個局域網環境。

DR模式是互聯網使用比較多的一種模式。

DR模式原理圖：

DR模式原理過程簡述：

VS/DR模式的工作流程圖如上圖所示，它的連接調度和管理與NAT和TUN中的一樣，它的報文轉發方法和前兩種不同。DR模式將報文直接路由給目標真實服務器。在DR模式中，調度器根據各個真實服務器的負載情況，連接數多少等，動態地選擇一臺服務器，不修改目標IP地址和目標端口，也不封裝IP報文，而是將請求報文的數據幀的目標MAC地址改為真實服務器的MAC地址。然后再將修改的數據幀在服務器組的局域網上發送。因為數據幀的MAC地址是真實服務器的MAC地址，并且又在同一個局域網。那么根據局域網的通訊原理，真實復位是一定能夠收到由LB發出的數據包。真實服務器接收到請求數據包的時候，解開IP包頭查看到的目標IP是VIP。（此時只有自己的IP符合目標IP才會接收進來，所以我們需要在本地的回環借口上面配置VIP。另：由于網絡接口都會進行ARP廣播響應，但集群的其他機器都有這個VIP的lo接口，都響應就會沖突。所以我們需要把真實服務器的lo接口的ARP響應關閉掉。）然后真實服務器做成請求響應，之后根據自己的路由信息將這個響應數據包發送回給客戶，并且源IP地址還是VIP。

DR模式小結：

1、通過在調度器LB上修改數據包的目的MAC地址實現轉發。注意源地址仍然是CIP，目的地址仍然是VIP地址。

2、請求的報文經過調度器，而RS響應處理后的報文無需經過調度器LB，因此并發訪問量大時使用效率很高（和NAT模式比）

3、因為DR模式是通過MAC地址改寫機制實現轉發，因此所有RS節點和調度器LB只能在一個局域網里面

4、RS主機需要綁定VIP地址在LO接口上，并且需要配置ARP抑制。

5、RS節點的默認網關不需要配置成LB，而是直接配置為上級路由的網關，能讓RS直接出網就可以。

6、由于DR模式的調度器僅做MAC地址的改寫，所以調度器LB就不能改寫目標端口，那么RS服務器就得使用和VIP相同的端口提供服務。

官方三種負載均衡技術比較總結表：

工作模式	VS/NAT	VS/TUN	VS/DR
Real server （節點服務器）	Config dr gw	Tunneling	Non-arp device/tie vip
Server Network	Private	LAN/WAN	LAN
Server number （節點數量）	Low 10-20	High 100	High 100
Real server gateway	Load balance	Own router	Own router
優點	地址和端口轉換	Wan環境加密數據	性能最高
缺點	效率低	需要隧道支持	不能跨域LAN

LVS調度算法

最好參考此文章：http://www.linuxvirtualserver.org/zh/lvs4.html

Lvs的調度算法決定了如何在集群節點之間分布工作負荷。當director調度器收到來自客戶端訪問VIP的上的集群服務的入站請求時，director調度器必須決定哪個集群節點應該處理請求。Director調度器用的調度方法基本分為兩類：

固定調度算法：rr，wrr，dh，sh

動態調度算法：wlc，lc，lblc，lblcr

算法	說明
rr	輪詢算法，它將請求依次分配給不同的rs節點，也就是RS節點中均攤分配。這種算法簡單，但只適合于RS節點處理性能差不多的情況
wrr	加權輪訓調度，它將依據不同RS的權值分配任務。權值較高的RS將優先獲得任務，并且分配到的連接數將比權值低的RS更多。相同權值的RS得到相同數目的連接數。
Wlc	加權最小連接數調度，假設各臺RS的全職依次為Wi，當前tcp連接數依次為Ti，依次去Ti/Wi為最小的RS作為下一個分配的RS
Dh	目的地址哈希調度（destination hashing）以目的地址為關鍵字查找一個靜態hash表來獲得需要的RS
SH	源地址哈希調度（source hashing）以源地址為關鍵字查找一個靜態hash表來獲得需要的RS
Lc	最小連接數調度（least-connection）,IPVS表存儲了所有活動的連接。LB會比較將連接請求發送到當前連接最少的RS.
Lblc	基于地址的最小連接數調度（locality-based least-connection）：將來自同一個目的地址的請求分配給同一臺RS，此時這臺服務器是尚未滿負荷的。否則就將這個請求分配給連接數最小的RS，并以它作為下一次分配的首先考慮。

LVS調度算法的生產環境選型：

1、一般的網絡服務，如http，mail，mysql等常用的LVS調度算法為：

a.基本輪詢調度rr

b.加權最小連接調度wlc

c.加權輪詢調度wrc

2、基于局部性的最小連接lblc和帶復制的給予局部性最小連接lblcr主要適用于web cache和DB cache

3、源地址散列調度SH和目標地址散列調度DH可以結合使用在防火墻集群中，可以保證整個系統的出入口唯一。

實際適用中這些算法的適用范圍很多，工作中最好參考內核中的連接調度算法的實現原理，然后根據具體的業務需求合理的選型。

以上兩篇LVS文章已經介紹了LVS的理論知識，本篇博文就介紹如何手動的配置LVS，目錄：

一、環境需求&安裝LVS軟件

二、手動配置LVS負載均衡器

三、RS節點服務器手動配置

四、測試LVS是否生效

五、部署成功后的另一些問題

一、環境需求&安裝LVS軟件

環境準備：三臺虛擬機

1）此環境是針對內部服務的LVS架構，如數據庫，緩存，共享存儲等業務。

虛擬機角色	IP地址	備注
LVS負載均衡器	192.168.41.181	VIP地址：192.168.40.17
http服務器RS1	192.168.41.31	?
http服務器RS2	192.168.41.33	?

安裝LVS軟件

1）在安裝LVS軟件之前，先確定兩條HTTPserver是能夠正常訪問的。

2）下載軟件

wget http://www.linuxvirtualserver.org/software/kernel-2.6/ipvsadm-1.24.tar.gz

這里我們使用的2.4版本，并且注意內核是2.6版本的，如果你的版本是6.X版本的話，那么可以使用2.6版本

3）編譯安裝

需要創建一個軟連接：ln -s /usr/src/kernels/2.6.18-238.el5-i686 /usr/src/linux

此處紅色許根據自己的系統來進行定義，可以使用tab鍵來補齊。

tar -zxf ipvsadm-1.24.tar.gz

cd ipvsadm-1.24

make

make install

lsmod |grep ip_vs

ipvsadm --》因為此時系統還沒有把ipvs模塊加載進系統，需要我們執行ipvsadm命令才會加載進去

或者modprobe ip_vs。

[root@localhost ipvsadm-1.24]# lsmod |grep ip_vs ip_vs_rr 6081 1 ip_vs 78081 3 ip_vs_rr

二、手動配置LVS負載均衡器

正常工作中是不會手動配置的，也不會使用腳本配置的。最終我們是通過配置文件生效的，結合keepalived來進行部署的。

1）負載均衡器上配置VIP地址

ifconfig eth0:1 192.168.40.17 netmask 255.255.254.0

route add -host 192.168.40.17 dev eth0

2）ipvsadm添加LVS服務

參數	參數說明
-A	-A --add-service 添加一個帶選項的虛擬服務。 Add a virtual service. A serviceaddress is uniquely defined by a triplet: IP address, portnumber, and protocol. Alternatively a virtualservice may be defined by a firewall-mark.
-t	指定虛擬服務器的IP地址和端口
-s	-s,--scheduler scheduling-method 調度算法
-p	會話保持按秒計算
-a	-a在對應的VIP下添加RS節點
-g	指定此LVS的工作模式為-g -g為DR模式
-l	指定LVS的工作模式為-l -l為tunnel模式
-m	指定LVS的工作模式為NAT模式
-w	指定RS節點的權重
-D	刪除虛擬服務 格式：ipvsadm-D -t|u|f service-address Delete a virtual service, alongwith any associated real servers.
-C	-C, --clear Clear the virtual server table清空lvs原有的配置。
-set	設置tcp tcpfn udp 的連接超時時間（一般來說高并發的時候小一點點。

ipvsadm -C #請用LVS原有的配置

ipvsadm -A -t 192.168.40.17:80 -s rr -p 20 #添加虛擬服務指定VIP

ipvsadm -a -t 192.168.40.17:80 -r 192.168.41.31:80 -g -w 10#針對虛擬服務添加RS節點

ipvsadm -a -t 192.168.40.17:80 -r 192.168.41.33:80 -g -w 10

ipvsadm -L -n #查看VIP和RS是否已經配置成功。

[root@localhost ~]# ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.40.17:80 rr persistent 20 -> 192.168.41.33:80 Route 10 0 0 -> 192.168.41.31:80 Route 10 0 0

LB上刪除虛擬服務

ipvsadm -D -t 192.168.40.17:80

三、RS節點服務器手動配置

1)添加lo端口的VIP&路由

ifconfig lo 192.168.40.17 netmask 255.255.255.255 (由于RS的VIP不是用來通訊，并且這里一定要設置24位掩碼）

route add -host 192.168.40.17 dev lo

2)ARP抑制

echo "1">/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2">/proc/sys/net/ipv4/conf/lo/arp_announce

echo "1">/proc/sys/net/ipv4/conf/all/arp_announce

echo "2">/proc/sys/net/ipv4/conf/all/arp_announce

四、測試LVS是否生效

在LB上面輸入命令ipvsadm -L -n就能夠查看LB上面的會話分配。在前面加上watch可以動態的查看ipvsadm的會話分配。watch ipvsadm -L -n.

1)測試RS節點是否正常訪問

2)測試從LB能否正常訪問RS

3)測試客戶端能否正常訪問VIP

在測試的時候可以先把防火墻關閉掉，一般按照這樣配置就能夠實現LVS的負載均衡了。

至此我們的LVS DR模式負載均衡已經配置完成了。至于不同的調度算法啊-s 不同的工作模式-g(DR) -l(TUNNEL) -m(NAT)服務器端基本上沒有什么差別。只是在客戶端上有一定的差別。

NAT模式：

客戶端同樣需要配置VIP，進行ARP抑制，并且要服務器端開啟內核轉發功能，配置LB的DIP(內網IP地址）作為默認網關。

開啟內核轉發功能：vi /etc/sysctl net.ipv4.ip_forword = 1

route add default gw 192.168.41.181

Tunnel模式：

客戶端需要先開啟Tunnel協議支持。

/sbin/modprobe ipip

/sbin/route add –host 192.168.40.17 devtun1

echo”1”>/proc/sys/net/ipv4/conf/tun1/arp-ignore

echo”2”>/proc/sys/net/ipv4/conf/tun1/arp_announce

echo”0” >/proc/sys/net/ipv4/conf/tun1/rp_filter

echo”1” >/proc/sys/net/ipv4/conf/tun1/forwarding

echo”1” >/proc/sys/net/ipv4/conf/all/arp_ignore

echo”2” >/proc/sys/net/ipv4/conf/all/ arp_announce

五、部署成功后的另一些問題

1）當我們的RS節點出現問題，LB如何知道。如果不知道是會把會話連接接續轉發到RS上面。

2）如果LB出現故障，那么整個網絡就出現故障。

針對上面的1問題，我們就需要一種RS節點健康檢查機制。定時的去檢測RS是否正常，如果出現不正常那么就把這個RS從VIP服務里面刪除掉。如果恢復正常了，就再把RS添加進來。針對2問題，我們可以另外再架設一臺LB服務器，作為備LB服務器。那么當主LB出現故障，備LB服務器就會啟動接管主LB服務器的工作，接管它的資源（IP地址，在網絡中的角色身份等）

而上面提到的這些我們就需要結合keepalived來完成。所以后續我們開始講keepalived+lvs結合適用。完成RS節點健康檢查和LVS的高可用性功能。

之前已經講解LVS原理，并且介紹了如果手動部署LVS。但由于我們需要進行RS節點服務器的健康檢查，還有要做LVS的HA。此文就主要介紹keepalived的原理，并且介紹如何部署keepalived做作為web服務器的HA。本文的目錄如下：

一、keepalived原理介紹

二、部署keepalived作為web服務器的HA

三、腳本實現監控httpd服務

一、keepalived原理介紹

1）keepalived簡介

Keepalived的功能有點像是兩個人互相看著一個工作，如果一個人離開崗位另外一個人就會接替，這個keepalived就是他們之間保持這樣“替換機制”的工具。keepalived是一個類似于layer3, 4 & 5交換機制的軟件，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測web服務器的狀態，如果有一臺web服務器死機，或工作出現故障，Keepalived將檢測到，并將有故障的web服務器從系統中剔除，當web服務器工作正常后Keepalived自動將web服務器加入到服務器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的web服務器。

Keepalived服務主要有兩大用途：heartbeat（高可用）&failover（健康檢測）

Keepalived服務主要截圖vrrp來完成這些工作的，以下我就來介紹下VRRP協議是怎樣的工作的，那么基本上keepalived的工作原理就是如此。

2）VRRP協議（VRRP Virtual Router Redundancy Protocol，虛擬路由冗余協議）

VRRP協議過程簡述：VRRP 將局域網的一組路由器（包括一個Master 即活動路由器和若干個Backup 即備份路由器）組織成一個虛擬路由器，稱之為一個備份組。這個虛擬的路由器擁有自己的IP 地址10.100.10.1（這個IP 地址可以和備份組內的某個路由器的接口地址相同，相同的則稱為ip擁有者），備份組內的路由器也有自己的IP 地址（如Master的IP 地址為10.100.10.2，Backup 的IP 地址為10.100.10.3）。局域網內的主機僅僅知道這個虛擬路由器的IP 地址10.100.10.1，而并不知道具體的Master 路由器的IP 地址10.100.10.2 以及Backup 路由器的IP 地址10.100.10.3。[1]它們將自己的缺省路由下一跳地址設置為該虛擬路由器的IP 地址10.100.10.1。于是，網絡內的主機就通過這個虛擬的路由器來與其它網絡進行通信。如果備份組內的Master 路由器壞掉，Backup 路由器將會通過選舉策略選出一個新的Master 路由器，繼續向網絡內的主機提供路由服務。從而實現網絡內的主機不間斷地與外部網絡進行通信。

VRRP原理：

二、部署keepalived作為web服務器的HA

1)部署兩臺apache web服務器

yum install httpd -y

/etc/init.d/httpd start

2)分別安裝keepalived軟件

#下載安裝

wget http://www.keepalived.org/software/keepalived-1.2.8.tar.gz

tar -zxf keepalived-1.2.8.tar.gz

cd keepalived-1.2.8

ll

./configure --prefix=/usr/local/keepalived

make

make install

#配置keepalived的自啟動&拷貝keepalived的執行程序

cp /usr/local/keepalive/sbin/keepalived/ /usr/sbin/

cp cp /usr/local/keepalived/sbin/keepalived /usr/sbin//usr/local/keepalived/sbin/keepalived

cp /usr/local/keepalived/sbin/keepalived /usr/sbin/

cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/

cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/

3）編輯主web和備web的keepalived配置文件

主web服務器的配置文件

[root@localhost keepalived-1.2.8]# cat /etc/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { #設置報警郵件地址，可多行每行一個。 752119102@qq.com } notification_email_from keepalived@localhost #設置郵件的發送地址 smtp_server 127.0.0.1 #設置SMTP server地址 smtp_connect_timeout 30 #設置SMTP 超時時間 router_id LVS_DEVEL #運行keepalived機器的一個標識 } vrrp_instance VI_1 { #定義一個vrrp實例，不同實例的實例編號不一樣。 state MASTER #定義在keepalived的角色MASTER表示為主服務器，BACKUP為備服務器。 interface eth0 #指定HA檢測的網絡接口 virtual_router_id 51 #虛擬路由標示，同一個實例里的路由標示相同，且唯一。MASTER和BACKUP的路由標識一樣，且唯一。 priority 100 #定義此服務器在此虛擬路由器中的優先級，優先級大權限高 advert_int 1 #檢測時間間隔 authentication { #設置驗證類型和密碼，主從的密碼必須相同，要不兩者不通訊。 auth_type PASS auth_pass 1111 } virtual_ipaddress { #設置虛擬IP地址，可以設置多個虛擬IP地址。 192.168.41.249 } }

備web服務器的配置文件

[root@localhost ~]# cat /etc/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { 752119102@qq.com } notification_email_from keepalive@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 51 priority 50 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.41.249 } }

啟動keepalived服務

/etc/init.d/keepalived start

/etc/init.d/keepalived stop

4)查看keepalived日志信息

主web服務器

Jan 14 20:27:41 localhost Keepalived_vrrp[20840]: Opening file '/etc/keepalived/keepalived.conf'. Jan 14 20:27:41 localhost Keepalived_vrrp[20840]: Configuration is using : 36304 Bytes Jan 14 20:27:41 localhost Keepalived_vrrp[20840]: Using LinkWatch kernel netlink reflector... Jan 14 20:27:41 localhost Keepalived[20837]: Starting VRRP child process, pid=20840 Jan 14 20:27:41 localhost Keepalived_vrrp[20840]: VRRP sockpool: [ifindex(2), proto(112), unicast(0), fd(11,12)] Jan 14 20:27:42 localhost Keepalived_vrrp[20840]: VRRP_Instance(VI_1) Transition to MASTER STATE Jan 14 20:27:43 localhost Keepalived_vrrp[20840]: VRRP_Instance(VI_1) Entering MASTER STATE Jan 14 20:27:43 localhost Keepalived_vrrp[20840]: VRRP_Instance(VI_1) setting protocol VIPs. Jan 14 20:27:43 localhost Keepalived_vrrp[20840]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.41.249 Jan 14 20:27:43 localhost Keepalived_vrrp[20840]: Netlink reflector reports IP 192.168.41.249 added Jan 14 20:27:43 localhost avahi-daemon[3207]: Registering new address record for 192.168.41.249 on eth0. Jan 14 20:27:43 localhost Keepalived_healthcheckers[20839]: Netlink reflector reports IP 192.168.41.249 added Jan 14 20:27:44 localhost avahi-daemon[3207]: Invalid query packet. Jan 14 20:27:46 localhost last message repeated 8 times Jan 14 20:27:48 localhost Keepalived_vrrp[20840]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.41.249 Jan 14 20:27:48 localhost avahi-daemon[3207]: Invalid query packet.

備web服務器日志

Jan 14 19:55:26 localhost Keepalived_vrrp[19423]: Opening file '/etc/keepalived/keepalived.conf'. Jan 14 19:55:26 localhost Keepalived_vrrp[19423]: Configuration is using : 36302 Bytes Jan 14 19:55:26 localhost Keepalived_vrrp[19423]: Using LinkWatch kernel netlink reflector... Jan 14 19:55:26 localhost Keepalived[19420]: Starting VRRP child process, pid=19423 Jan 14 19:55:26 localhost Keepalived_vrrp[19423]: VRRP_Instance(VI_1) Entering BACKUP STATE Jan 14 19:55:26 localhost Keepalived_vrrp[19423]: VRRP sockpool: [ifindex(2), proto(112), unicast(0), fd(11,12)]

當主web服務器的keepalived停掉后，及主keepalived重新啟動時的日志：

Jan 14 20:25:57 localhost Keepalived_vrrp[19423]: VRRP_Instance(VI_1) Transition to MASTER STATE Jan 14 20:25:58 localhost Keepalived_vrrp[19423]: VRRP_Instance(VI_1) Entering MASTER STATE Jan 14 20:25:58 localhost Keepalived_vrrp[19423]: VRRP_Instance(VI_1) setting protocol VIPs. Jan 14 20:25:58 localhost Keepalived_vrrp[19423]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.41.249 Jan 14 20:25:58 localhost Keepalived_vrrp[19423]: Netlink reflector reports IP 192.168.41.249 added Jan 14 20:25:58 localhost Keepalived_healthcheckers[19422]: Netlink reflector reports IP 192.168.41.249 added Jan 14 20:26:03 localhost Keepalived_vrrp[19423]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.41.249 ###主keepalived重新啟動后 Jan 14 20:27:42 localhost Keepalived_vrrp[19423]: VRRP_Instance(VI_1) Received higher prio advert Jan 14 20:27:42 localhost Keepalived_vrrp[19423]: VRRP_Instance(VI_1) Entering BACKUP STATE Jan 14 20:27:42 localhost Keepalived_vrrp[19423]: VRRP_Instance(VI_1) removing protocol VIPs.

并且通過tcpdump vrrp能夠看到兩者之間的通訊

[root@localhost ~]# tcpdump vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 20:38:58.657600 IP 192.168.41.33 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 20:38:59.658287 IP 192.168.41.33 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 20:39:00.659280 IP 192.168.41.33 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 20:39:01.660358 IP 192.168.41.33 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 20:39:02.661203 IP 192.168.41.33 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 20:39:03.662205 IP 192.168.41.33 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20 20:39:04.663129 IP 192.168.41.33 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20

三、腳本實現監控httpd服務

目前keepalived能夠實現當我們的主web宕機或者網絡出現故障時進行切換，但如果僅是httpd進程出現故障，所以我們就需要寫一點實時監控httpd進程狀態的腳本，即如果進程出現問題我們就進行切換。

腳本內容：

#!/bin/bash # QQ:752119102 while true do httpdpid=`ps -C httpd --no-heading |wc -l` if [ $httpdpid -eq 0 ];then /etc/init.d/httpd start sleep 5 httpdpid=`ps -C httpd --no-heading |wc -l` if [ $httpdpid -eq 0 ];then /etc/init.d/keepalive stop fi fi sleep 5 done

即當我們的httpd進程被停止了，并且無法重啟我們會將keepalived進行停止，讓備web服務器進行接管，成為主WEB服務器提供服務。

到此我們已經能夠輕松的部署keepalived讓它作為web服務器的HA.

本文我們主要講解的是LVS通過keepalived來實現負載均衡和高可用，而不是我們第三篇文章介紹的通過手動的方式來進行配置。通過腳本的方式來顯示RS節點的健康檢查和LVS的故障切換。此文會通過一個實例來講解，本文目錄如下：

一、實驗環境需求&準備

二、配置keepalived實現負載均衡&高可用

一、實驗環境需求&準備

我們這次實驗要完成的一個架構如下圖所示，我們通過LVS-DR-MASTER,LVS-DR-BACKUP作為LVS負載均衡調度器，并且兩者之間通過keepalived來兩者之間的HA。keepalived本身就是為了LVS為開發的，所以說我們通過keepalived來進行LVS的配置就顯得十分的方便。而且keepalived是直接操作ip_vs不用通過ipvsadm，所以更加方便。

1）實驗架構圖&需求表：

角色	IP地址	備注
主LVS調度器（MASTER)	192.168.41.181	使用keepalived配置
備LVS調度器（BACKUP)	192.168.41.251	?
HTTP服務器（RS1)	192.168.41.31	apache服務器（一般生產環境需要外網IP地址，這里用內網IP地址替代）
HTTP服務器（RS2)	192.168.41.33	?
虛擬IP地址（VIP)	192.168.41.249	虛擬IP地址

2）部署http服務器，驗證能正常訪問

這里就不多費篇幅介紹了，就是要保證http能正常訪問。

二、配置keepalived實現負載均衡&高可用

1）安裝keepalived軟件

wget http://www.keepalived.org/software/keepalived-1.2.8.tar.gz

tar -zxf keepalived-1.2.8.tar.gz

cd keepalived-1.2.8

./configure --prefix=/usr/local/keepalived

make

make install

#配置keepalived的自啟動&拷貝keepalived的執行程序

cp /usr/local/keepalived/sbin/keepalived /usr/sbin/

cp /usr/local/keepalived/sbin/keepalived /usr/sbin/

cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/

cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/

#開啟內核的轉發功能

vi /etc/sysctl net.ipv4.ip_forword = 1

2）配置LVS-DR-MASK的keepalived.conf配置文件

! Configuration File for keepalived global_defs { notification_email { 752119102@qq.com #設置報警郵箱，一般不再這做，而是用其他方式報警。 } notification_email_from keepalived@localhost #設定發送郵件地址 smtp_server 127.0.0.1 #設定發送郵件服務器 smtp_connect_timeout 30 #設定SMTP連接超時時間 router_id LVS_DEVEL #查閱說明文檔得知route_id配置是為了標識當前節點，我將其設置為NodeA。當然兩個節點的此項設置可相同，也可不相同。 } vrrp_instance VI_1 { #定義虛擬路由實例，不同實例ID不同。 state MASTER #定義服務器在keepalived中的角色主服務器 interface eth0 #定義進行檢測的端口eth0 virtual_router_id 51 #定義虛擬路由ID，同一個實例的主從一樣。 priority 100 #定義在虛擬路由器組的權限，越大越高 advert_int 1 #定義檢測時間間隔 authentication { #定義認證方式密碼，主從必須一樣 auth_type PASS auth_pass 1111 } virtual_ipaddress { #指定虛擬IP地址 192.168.41.249 } } virtual_server 192.168.41.249 80 { #定義虛擬服務，需指定IP地址和端口，空格隔開。 delay_loop 6 #定義RS運行情況監測時間間隔 lb_algo rr #定義負載調度算法 lb_kind DR #定義LVS的工作模式 nat_mask 255.255.255.0 #定義虛擬服務的mask persistence_timeout 50 #定義會話保持時間，S為單位 protocol TCP #指定轉發協議 real_server 192.168.41.31 80 { #定義真實服務器IP地址和端口 weight 1 #定義RS的權重 TCP_CHECK{ #RS server健康檢查部分 connect_timeout 10 #定義超出10s連接超時 nb_get_retry 3 #定義重試次數 delay_before_retry 3 #定義重試時間間隔 connect_port 80 #定義健康檢查端口 } real_server 192.168.41.33 80 { weight 1 TCP_CHECK{ connect_timeout 10 nb_get_retry 3 delay_before_retry 3 connect_port 80 } }

3）配置LVS-DR-BACKUP的keepalived.conf配置文件

! Configuration File for keepalived global_defs { notification_email { 752119102@qq.com #設置報警郵箱，一般不再這做，而是用其他方式報警。 } notification_email_from keepalived@localhost #設定發送郵件地址 smtp_server 127.0.0.1 #設定發送郵件服務器 smtp_connect_timeout 30 #設定SMTP連接超時時間 router_id LVS_DEVEL #負載均衡器標示，在局域網內是唯一的 } vrrp_instance VI_1 { #定義虛擬路由實例，不同實例ID不同。 state BACKUP #定義服務器在keepalived中的角色 interface eth0 #定義進行檢測的端口eth0 virtual_router_id 51 #定義虛擬路由ID，同一個實例的主從一樣。 priority 50 #定義在虛擬路由器組的權限，越大越高 advert_int 1 #定義檢測時間間隔 authentication { #定義認證方式密碼，主從必須一樣 auth_type PASS auth_pass 1111 } virtual_ipaddress { #指定虛擬IP地址 192.168.41.249 } } virtual_server 192.168.41.249 80 { #定義虛擬服務，需指定IP地址和端口，空格隔開。 delay_loop 6 #定義RS運行情況監測時間間隔 lb_algo rr #定義負載調度算法 lb_kind DR #定義LVS的工作模式 nat_mask 255.255.255.0 #定義虛擬服務的mask persistence_timeout 50 #定義會話保持時間，S為單位 protocol TCP #指定轉發協議 real_server 192.168.41.31 80 { #定義真實服務器IP地址和端口 weight 1 #定義RS的權重 TCP_CHECK{ #RS server健康檢查部分 connect_timeout 10 #定義超出10s連接超時 nb_get_retry 3 #定義重試次數 delay_before_retry 3 #定義重試時間間隔 connect_port 80 #定義健康檢查端口 } real_server 192.168.41.33 80 { weight 1 TCP_CHECK{ connect_timeout 10 nb_get_retry 3 delay_before_retry 3 connect_port 80 }

說明：這里主LVS-DR-MASTER和LVS-DR-BACKUP之間的配置的差別就只有紅色部分：HA的角色（MASTER,BACKUP)和優先級不同，還有router_id。

4）客戶端配置LVS參數

客戶端需要做的工作就是綁定我們的VIP在lo口，并且進行ARP抑制，之前的文章已經提過此方法咯。現在我們就換成將配置寫成腳本來執行。

腳本內容：

[root@RS2 ~]# cat lvs-client.sh #!/bin/bask # 752119102@qq.com # . /etc/rc.d/init.d/functions VIP=( 192.168.41.249 ) function start(){ for ((i=0;i<`echo ${#VIP[*]}`;i++)) do echo ${i} ${VIP[$i]} ifconfig lo:${i} ${VIP[$i]} netmask 255.255.255.255 up route add -host ${VIP[$i]} dev lo done echo "1">/proc/sys/net/ipv4/conf/lo/arp_ignore echo "2">/proc/sys/net/ipv4/conf/lo/arp_announce echo "1">/proc/sys/net/ipv4/conf/all/arp_announce echo "2">/proc/sys/net/ipv4/conf/all/arp_announce } function stop(){ for ((i=0;i<${#VIP[*]};i++)) do echo ${i} ${VIP[$i]} ifconfig lo:${i} ${VIP[$i]} netmask 255.255.255.255 up route del -host ${VIP[$i]} dev lo:${i} done } case "$1" in start) start exit ;; stop) stop exit ;; *) echo "You must use $0:stop|start" ;; esac

5）測試實驗結果

如果測試部成功可以按照三角的排查原理來進行排查，顯示client到RS端是否能通訊，LB到RS能否通訊，client到LB是否能通訊，client到VIP是否能夠通訊。并且查看LVS的運行狀態。一定要確保keepalived.conf這個配置文件是正確的。