LVS 介紹
一.進行lvs叢集的搭建
二.後端（real server)提供服務
- real server禁用arp
- 禁用arp協定：
三、LVS叢集工作模式
- DR直接路由模式
- NAT模式
- TUN 工作模式（隧道工作模式)
四.iptable（防火牆）與LVS排程是否有沖突
- 某台RealServer down了，怎麼辦？
五.Keepalive+LVS高可用
- 修改keepalive配置檔案

LVS 介紹

LVS是Linux Virtual Server的簡稱，也就是Linux虛拟伺服器，該項目在Linux核心中實作了基于IP的資料請求負載均衡排程方案，終端網際網路使用者從外部通路公司的外部負載均衡伺服器，終端使用者的Web請求會發送給LVS排程器，排程器根據自己預設的算法決定将該請求發送給後端的某台Web伺服器

将外部的請求平均分發給後端的所有伺服器，終端使用者通路LVS排程器雖然會被轉發到後端真實的伺服器，但如果真實伺服器連接配接的是相同的存儲，提供的服務也是相同的服務，最終使用者不管是通路哪台真實伺服器，得到的服務内容都是一樣的！！

LVS工作模式分為NAT模式、TUN模式、以及DR模式。

一.進行lvs叢集的搭建

環境搭建：client --> DR -->RS --client

安裝的是管理工具，第一種叫ipvsadm，第二種叫keepalive

ipvsadm是通過指令行管理，而keepalive讀取配置檔案管理

server1：

yum install -y ipvsadm

建立一個虛拟服務，它需要有一個vip（虛拟ip），這個ip在部署完高可用後可以在不同節點之間浮動

ip addr add 172.25.1.100/24 dev eth0

然後檢視ip

ip addr

LVS負載均衡-叢集搭建，叢集工作模式，keepalive結合lvs的高可用LVS 介紹一.進行lvs叢集的搭建二.後端（real server)提供服務三、LVS叢集工作模式四.iptable（防火牆）與LVS排程是否有沖突五.Keepalive+LVS高可用

添加虛拟服務以及将其關聯到真實伺服器上去

ipvsadm -A -t 172.25.1.100:80 -s rr       # 添加虛拟服務
ipvsadm -a -t 172.25.1.100:80 -r 172.25.1.2:80 -g    #将虛拟服務關聯到真實服務上
ipvsadm -a -t 172.25.1.100:80 -r 172.25.1.3:80 -g
 
#LVS預設無80端口，需另外添加新的虛拟IP記錄

添加之後，檢視配置結果

可以看到server2,server3都同步了

ipvsadm -ln

二.後端（real server)提供服務

在server2上:

yum install -y httpd
systemctl enable --now httpd
echo server2>/var/www/html/index.html

server3上：

yum install -y httpd
systemctl enable --now httpd
echo server3>/var/www/html/index.html

real server禁用arp

##在DR(直連)模式中，用戶端想要通過vip通路到真實後端的資源，要求排程節點和後端都要有相同的vip，但是同時會有這樣一個問題産生：

DR模式下，排程節點和real server真實伺服器在一個vlan（同一個網段）裡面，并且擁有相同的vip，那麼其它主機通路vip的時候如何能夠根據實作定義好的排程算法正确的在兩個real server之間完成排程呢？

我們可以禁用後端的arp（位址廣播協定），讓主機不要對外廣播自己的vip位址，就相當于不要告訴别人我有這個ip，鍊路層的傳輸隻需要mac位址而不需要通過ip

我們在真機curl一下添加的vip位址

curl 172.25.1.100

通路不到資源但是在server1上可以看到排程次數：

ipvsadm -ln檢視排程次數：

因為沒有在server2,3上添加vip

給兩台伺服器上的網卡綁定VIP位址

[[email protected] ~]# ip addr add 172.25.1.100/32 dev eth0
[[email protected] ~]# ip addr add 172.25.1.100/32 dev eth0

再次在真機上curl 172.25.1.100

發現可以通路到資源，可以輪詢排程

但是，現在的負載均衡還是有問題，因為此時能夠負載均衡隻是因為用戶端随機通路到了server1上的vip是以才能夠正常排程，正常情況下，server1、2、3上都有vip，是以用戶端通路vip的時候可能會随機通路到這三個節點的任何一個節點上，那麼我們該如何保證用戶端在通路vip的時候隻能通路到排程節點server1呢？這就需要禁用server12和server13節點的arp協定，讓它們不對外廣播vip位址

舉個例子：

我們在真機上先抓出ip位址

然後删掉vip

再次抓出ip為空

arp -d 172.25.1.100
arp -an | grep 100

這時候重新ping 172.25.1.100就可以使得vip重新過來

ping 172.25.1.100

arp -an | grep 100

但是仔細觀察兩次抓出的ip後面at後的資料不一樣！！！

因為第二次連接配接的是server3的vip！！！

我們重新curl 172.25.1.100觀察

全部都是server3！！！

我們再删掉vip,重新ping,抓出ip位址：

我們發現at後的參數和最之前的一樣了！

再一次curl 172.25.1.100，發現又可以2，3之前負載均衡

但是這也是不對的，我們需要實作的是一直在server2,server3上負載均衡！

禁用arp協定：

使用arptables_jf工具（相當于arp防火牆）禁用

arptable隻針對arp協定生效，隻控制arp，不影響其它協定

在server2,server3上都要執行：

yum install arptables.x86_64 -y
[[email protected] html]# arptables -A INPUT -d 172.25.1.100 -j DROP
[[email protected] html]# arptables -A OUTPUT -s 172.25.1.100 -j mangle --mangle-ip-s 172.25.1.2
systemctl restart arptables.service
 
 
[[email protected] html]# arptables -A INPUT -d 172.25.1.100 -j DROP
[[email protected] html]# arptables -A OUTPUT -s 172.25.1.100 -j mangle --mangle-ip-s 172.25.1.3
systemctl restart arptables.service

檢視政策

和前面一樣，删掉ip節點重新ping一下，發現查到的ip位址的資料沒有變化了，都是server1！！

arp -an| grep 100

arp -d 172.25.1.100

ping 172.25.1.100

arp -an| grep 100

可以看到at後面的資訊都是79:15:a1

這時候再進行負載均衡測試發現ok了！！

而且我們可以看到在server1上檢視ip addr顯示的 eth0的網絡資訊也是79:15:a1!!!

三、LVS叢集工作模式

DR直接路由模式

client -> DR -> RS ->client

用戶端通路DR，DR通路RS，RS直接把資料包定向到了用戶端

在LVS的三種工作模式中，DR模式的工作效率最高，它工作在第二層資料鍊路層，直接通過mac位址轉發資料，它僅僅承擔轉發工作，直接把資料往後甩，最後傳回給用戶端，性能非常高。

三種工作模式中NAT性能最差，因為需要進行位址轉換，資料流一進一出原路徑傳回需要經過排程器，隧道模式和DR模式性能最接近，隧道模式需要支援廣域網、多個網段，而DR直連模式要求必須要在一個vlan裡面。

NAT模式

client --> vs --> rs --> vs --> client

通過網絡位址轉換，排程器重寫請求封包的目标位址，根據預設的排程算法，将請求分派給後端的真實伺服器，真實伺服器的響應封包處理之後，傳回時必須通過排程器，經過排程器時封包的源位址被重寫，再傳回給客戶，完成整個副在排程過程。

TUN 工作模式（隧道工作模式)

客戶請求包封裝在一個IP tunnel裡面，然後發送給RS節點伺服器，節點伺服器接收到之後解開IP tunnel後，進行響應處理。并且直接把包通過自己的外網位址發送給客戶不用經過LB伺服器

缺點在于：

1、RS配置複雜（IPIP子產品）

2、RS上綁定VIP，風險比較大

四.iptable（防火牆）與LVS排程是否有沖突

我們需要考慮一個問題：iptable防火牆與LVS排程是否有沖突？哪個優先級更高一點呢？

那麼我們在server1也也裝上apache服務編寫釋出頁，再次通路vip，lvs是否能将我們的請求排程到server2和server3上面而不排程server1呢?

在server1上：

yum install -y httpd
systemctl start httpd
echo server1 > /var/www/html/index.html
curl localhost

然後再次到真機進行負載均衡測試：

發現還是OK的，并沒有排程server1

我們發現排程正常，那麼這個過程是怎麼實作的呢？server1排程節點上的apache為什麼不會被通路到呢？

檢視iptables -L

發現請求進來時，先到input鍊中，但是由于server1上有lvs政策，是以把需求轉發到了rs的 80端口上

接下來我們在防火牆INPUT鍊中添加相關政策再進行通路測試，

在server1排程節點上添加防火牆政策：所有通路172.25.1.100的請求都丢棄，這時候我們來在用戶端通路172.25.1.100,觀察是否能夠正常完成排程，如果無法排程，則說明防火牆政策優先級高，否則反之

在server1上

iptables -A INPUT -d 172.25.1.100 -j DROP

然後iptables -nL檢視政策已經删掉

再次負載均衡檢視發現無響應

由以上實驗可知：防火牆優先級最高，防火牆資料包過濾防火牆，隻要資料包進來就會受到它的控制，這時候都輪不到ipvs生效！！

某台RealServer down了，怎麼辦？

server2或者server3上的httpd停掉！

systemctl stop httpd，然後進行負載均衡測試：

此時排程器依然正常工作，但是用戶端将會有錯誤連接配接提示，這就說明排程器并不關心後端real server的死活，即使已經down掉了也依然會對其進行排程！！

我們這時候，隻需要删掉server2,或者server3上的排程政策，這時候用戶端在通路的時候就不會有錯誤資訊提示了

ipvsadm -d -t 172.25.1.100:80 -r 172.25.1.2

ipvsadm -ln

發現server2已經不再政策裡面了！！

再一次在用戶端負載均衡測試：

不會報錯！

五.Keepalive+LVS高可用

Keepalived 一方面具有配置管理LVS的功能，同時還具有對LVS下面節點進行健康檢查的功能，另一方面也可實作系統網絡服務的高可用功能。

開啟一台虛拟機server4準備測試lvs的高可用！！

[[email protected] ~]# yum install keepalived -y
[[email protected] ~]# yum install   ipvsadm keepalived -y

清除之前server1上的ipvsadm政策：

ipvsadm -C

删除server1上的vip

ip addr del 172.25.1.100/24 dev eth0

ipvsadm -ln檢視策是空的

修改keepalive配置檔案

cd /etc/keepalived
vim keepalived.conf 

global_defs {
  notification_email {
   [email protected]              %郵件通知，如果主機聯網的話可以寫外部郵箱，用于通知叢集狀态，寫localhost本機的話需要安裝mailx
  }
  notification_email_from [email protected]      %郵件來源
  smtp_server 127.0.0.1         %必須是本機
  smtp_connect_timeout 30
  router_id LVS_DEVEL
  vrrp_skip_check_adv_addr
  #vrrp_strict                #禁掉這個選項
  vrrp_garp_interval 0
  vrrp_gna_interval 0
}

vrrp_instance VI_1 {                   %高可用部分，vrrp協定巧妙利用了路由器硬體的備援
   state MASTER                 %主排程節點
   interface eth0
   virtual_router_id 1  #這個寫自己的數字
   priority 100                %優先級，隻要設定backup優先級比master優先級低就可以
   advert_int 1                %與backup之間每秒發一次心跳
   authentication {            %認證
       auth_type PASS
       auth_pass 1111
   }
   virtual_ipaddress {
       172.25.1.100   # 寫vip
   }
}

virtual_server 172.25.1.100 80 {       %這部分相當于将lvs的政策以文本的方式寫出來了，叢集将會根據這部分内容來制定lvs政策
   delay_loop 6                  %每隔6秒鐘對後端做一次健康檢查
   lb_algo rr                   %定義排程算法
   lb_kind DR                  %lvs模式（注意大小寫）
   #persistence_timeout 50     %50秒内同一個用戶端發過來的請求将會交給同一個後端處理，為了看到效果，建議注釋掉
   protocol TCP

   real_server 172.25.1.2 80 {
       weight 1             %權重
       TCP_CHECK { 
              connect_timeout 3
              nb_get_retry 3
              delay_before_retry 3
       }
   }
   real_server 172.25.1.3 80 {
       weight 1
       TCP_CHECK {
             connect_timeout 3
           	 nb_get_retry 3
          	 delay_before_retry 3
       }
   }
}

修改之後重新開機服務：

systemctl start keepalived

把2,3上的httpd服務都啟動一下：

在真機負載均衡恢複：

這個時候如果停掉server3的httpd服務：

在server1上檢視ipvsadm -ln

會提示有郵件

yum install -y mailx

下在完成之後

mail檢視郵件

可以看到server3的服務停掉的消息

這個時候把server2也停掉httpd

此時打開前面下載下傳好的server4

把server1上的 /etc/keepalived/keepalived.conf 複制到server4上

scp /etc/keepalived/keepalived.conf server4:/etc/keepalived/

修改一下：修改優先級為50和state為backup

還有

然後啟動服務“：

啟動server2,server3的httpd服務

systemctl start keepalived.service

ipvsadm -ln

ip addr

發現vip也出現了！

檢視server1的日志： cat /var/log/messages

檢視server4的日志：

用戶端通路可以實作負載均衡

此時将server1的keepalive down掉之後，server4将接管成為master，并且獲得vip和ipvs政策，仍然不影響用戶端的正常通路，排程依然可以進行

此時如果server1再次啟開keepalive,則server4又會稱為backup，vip和ipvs政策都會遷移到server11上，因為server11優先級更高

我們停掉server1的keepalive

systemctl stop keepalived

檢視server4的日志：發現它變為了master

vip也飄過來了

重新啟動server1的keepalived服務：

我們可以看到server1上的日志，顯示server1又接管了master

而且在server1down之後，用戶端的負載均衡是好的，重新啟動server1之後

用戶端的負載均衡也是好的！不影響客戶的使用！

LVS負載均衡-叢集搭建，叢集工作模式，keepalive結合lvs的高可用LVS 介紹一.進行lvs叢集的搭建二.後端（real server)提供服務三、LVS叢集工作模式四.iptable（防火牆）與LVS排程是否有沖突五.Keepalive+LVS高可用

目錄：

LVS 介紹

一.進行lvs叢集的搭建

二.後端（real server)提供服務

real server禁用arp

禁用arp協定：

三、LVS叢集工作模式

DR直接路由模式

NAT模式

TUN 工作模式（隧道工作模式)

四.iptable（防火牆）與LVS排程是否有沖突

某台RealServer down了，怎麼辦？

五.Keepalive+LVS高可用

修改keepalive配置檔案

繼續閱讀

Apache (You don't have permission to access / on this server.）

debian9更新4.9.0核心到4.19.2核心過程

centOS7 配置 vsftpd 虛拟使用者及權限Vsftpd配置虛拟使用者及權限

linux-svn解除安裝與安裝

vsftp虛拟多使用者多權限一鍵部署腳本

Ubuntu14.04 LTS下安裝mongodb

httpd服務的部署、啟動、配置和簡單優化一、部署二、啟動三、配置檔案

配置網頁内容通路

手動安裝Intel network I217-LM網卡的Linux驅動

禁止ubuntu系統彈出報錯界面

Ubuntu Linux下Apache的配置檔案

samba伺服器的功能

【Linux】UDP廣播封包接收速率問題

Linux裝置模型（中）之上層容器

PowerPC平台 Linux移植三