Keepalived+LVS+nginx搭建nginx高可用集群

nginx是一款非常優秀的反向代理工具,支持請求分發,負載均衡,以及緩存等等非常實用的功能。在請求處理上,nginx採用的是epoll模型,這是一種基於事件監聽的模型,因而其具備非常高效的請求處理效率,單機併發能力能夠達到上百萬。nginx接收到的請求可以通過負載均衡策略分發到其下一級的應用服務器,這些服務器一般是以集群方式部署的,因而在性能不足的情況下,應用服務器可以通過加機器的方式擴展流量。此時,對於一些特大型的網站,性能的瓶頸就來自於nginx了,因為單機的nginx的併發能力是有上限的,而nginx本身是不支持集群模式的,因而此時對nginx的橫向擴展就顯得尤為重要。

Keepalived+LVS+nginx搭建nginx高可用集群

keepalived是一款服務器狀態檢測和故障切換的工具。在其配置文件中,可以配置主備服務器和該服務器的狀態檢測請求。也就是說keepalived可以根據配置的請求,在提供服務期間不斷向指定服務器發送請求,如果該請求返回的狀態碼是200,則表示該服務器狀態是正常的,如果不正常,那麼keepalived就會將該服務器給下線掉,然後將備用服務器設置為上線狀態。

lvs是一款用於四層負載均衡的工具。所謂的四層負載均衡,對應的是網絡七層協議,常見的如HTTP協議是建立在七層協議上的,而lvs作用於四層協議上,也即:傳輸層,網絡層,數據鏈路層和物理層。這裡的傳輸層主要協議有TCP和UDP協議,也就是說lvs主要支持的方式是TCP和UDP。也正是因為lvs是處於四層負載均衡上的,因而其處理請求的能力比常見的服務器要高非常多,比如nginx的請求處理就是建立在網絡七層上的,lvs的負載均衡能力是nginx的十倍以上。

通過上面的介紹,我們可以發現,在特大型網站中,應用服務器是可以橫向擴容的,而nginx是不支持橫向擴容的,此時nginx就會成為性能瓶頸。而lvs是一款負載均衡工具,因而如果我們結合lvs和nginx,那麼就可以通過部署多臺nginx服務器,通過lvs的負載均衡能力,將請求均衡的分發到各個nginx服務器上,再由nginx服務器分發到各個應用服務器,這樣,我們就實現了nginx的橫向擴展了。由於nginx本質上也是一款應用服務器,因而其也有可能宕機,因而這裡結合keepalived就可以實現nginx的故障檢測和服務切換。也就是說,通過keepalived+lvs+nginx,我們實現了nginx的高可用集群模式。

Keepalived+LVS+nginx搭建nginx高可用集群

在上面的介紹中,我們會注意到,雖然keepalived+lvs+nginx實現了nginx的集群模式,但是在我們使用nginx的時候,其本身是有一個ip和端口的,默認監聽的端口是80和443,那麼lvs是如何實現將請求分發給具有不同ip和端口的nginx服務器的呢?這裡就是通過虛擬ip實現的,所謂虛擬ip就是對外提供一個公共的ip,外部客戶端請求的都是這個ip,lvs在接收到虛擬ip的請求之後,通過配置的調度器和負載均衡策略,選擇一個目標nginx服務器,然後將請求轉發給該服務器。這裡lvs有兩個概念,就是調度器和負載均衡策略,所謂的調度器指的是lvs將會以何種方式處理請求和響應數據,其主要有三種調度器:

  • Virtual Server via Network Address Translation(VS/NAT):這種方式的主要原理是,用戶發送請求到虛擬ip上後,lvs會根據負載均衡算法選擇一個目標處理服務,然後將請求報文中的目標ip地址修改為計算得到的目標服務器,並且發送給該服務器。對於響應的報文,調度器會將目標服務器返回的響應數據中的源地址修改為虛擬ip地址。通過這種方式,對客戶端而言,其形式上面向的是一臺服務器。不過這種方式的缺點在於,所有的響應數據都需要通過調度器,如果請求量比較大的情況下,那麼調度器就會成為整個系統的瓶頸。
  • Virtual Server via IP Tunneling(VS/TUN):這種方式主要解決的就是VS/NAT中,響應數據會經過調度器的問題。同VS/NAT一樣 ,調度器還是會接收請求的數據,並且將報文中的目標ip修改為目標服務的ip,但是在目標服務處理完數據之後,其會直接將響應報文中的源ip修改為虛擬ip,然後將請求發送給客戶端。通過這種方式,響應數據就由各個目標服務進行了處理,而無需通過調度器進行返回,這種方式會大大提高系統的吞吐量,而且由於一般請求報文比響應報文小很多,調度器也只需要處理請求報文,那麼系統的整體負載將會被均攤到各個服務器上。
  • Virtual Server via Direct Routing(VS/DR):這種方式相對於VS/TUN,其主要區別在於,VS/NAT是將請求報文中的ip地址修改為目標服務的ip地址,而VS/DR則是直接將請求報文中的MAC地址修改為目標地址,這種方式效率會更高,因為VS/TUN中的ip地址最終還是需要轉換為MAC地址來發送數據的。

1. 環境準備

1. VMware;
2. 4臺CentOs7虛擬主機:172.16.28.130, 172.16.28.131, 172.16.28.132, 172.16.28.133
3. 系統服務:LVS, Keepalived
4. Web服務器:nginx
5. 集群搭建:LVS DR模式

2. 軟件安裝

在四臺虛擬機上,我們以如下方式搭建集群:

172.16.28.130 lvs+keepalived
172.16.28.131 lvs+keepalived
172.16.28.132 nginx
172.16.28.133 nginx

這裡我們使用172.16.28.130 和172.16.28.131 兩臺機器作為lvs+keepalived 的工作機器,也就是說這兩臺機器的作用主要是進行負載均衡和故障檢測和下線的;我們使用172.16.28.132和172.16.28.133 兩臺機器作為應用服務器,主要是對外提供服務的。這四臺服務器作為整個後端集群服務,並且對外提供的虛擬ip是172.16.28.120 。需要說明的是,這裡的keepalived 所檢測的服務是兩臺lvs 服務器,這兩臺服務器,一臺作為master服務器,一臺作為backup服務器,兩者在負載均衡的配置上是完全一樣的。在正常情況下,客戶端請求虛擬ip的時候,lvs 會將該請求轉發到master服務器上,然後master服務器根據配置的負載均衡策略選擇一臺應用服務器,並且將請求發送給該應用服務器進行處理。如果在某個時刻,lvs的master服務器由於故障宕機了,keepalived就會檢測到該故障,並且進行故障下線,然後將backup機器上線用於提供服務,從而實現故障轉移的功能。

2.1 lvs+keepalived安裝

在172.16.28.130 和172.16.28.131 上安裝ipvs和keepalived:

# 安裝ipvs
sudo yum install ipvsadm
# 安裝keepalived
sudo yum install keepalived

在172.16.28.132 和172.16.28.133 上安裝nginx:

# 安裝nginx
sudo yum install nginx

需要注意的是,在兩臺nginx服務器上需要將防火牆關閉,否則lvs+keepalived的兩臺機器就無法將請求發送到兩臺nginx服務器上來:

# 關閉防火牆
systemctl disable firewalld.service

查看兩臺負載均衡機器是否支持lvs:

sudo lsmod |grep ip_vs
# 如果看到如下結果,則說明是支持的
[zhangxufeng@localhost ~]$ sudo lsmod|grep ip_vs
ip_vs 145497 0
nf_conntrack 137239 1 ip_vs
libcrc32c 12644 3 xfs,ip_vs,nf_conntrack

如果上述命令沒有任何結果,則執行sudo ipvsadm 命令啟動ipvs之後,再通過上述命令進行查看即可。啟動ipvs之後,我們就可以在/etc/keepalived/ 目錄下編輯keepalived.conf 文件,我們以172.16.28.130 機器作為master機器,master節點配置如下:

# Global Configuration
global_defs {
lvs_id director1 # 指定lvs的id
}
# VRRP Configuration
vrrp_instance LVS {
state MASTER\t# 指定當前節點為master節點
interface ens33\t# 這裡的ens33是網卡的名稱,通過ifconfig或者ip addr可以查看
virtual_router_id 51\t# 這裡指定的是虛擬路由id,master節點和backup節點需要指定一樣的
priority 151\t# 指定了當前節點的優先級,數值越大優先級越高,master節點要高於backup節點
advert_int 1\t# 指定發送VRRP通告的間隔,單位是秒
authentication {
auth_type PASS\t# 鑑權,默認通過
auth_pass 123456\t# 鑑權訪問密碼
}
virtual_ipaddress {
172.16.28.120\t# 指定了虛擬ip
}
}
# Virtual Server Configuration - for www server
# 後臺真實主機的配置
virtual_server 172.16.28.120 80 {
delay_loop 1\t# 健康檢查的時間間隔
lb_algo rr\t# 負載均衡策略,這裡是輪詢
lb_kind DR\t# 調度器類型,這裡是DR
persistence_time 1\t# 指定了持續將請求打到同一臺真實主機的時間長度
protocol TCP\t# 指定了訪問後臺真實主機的協議類型
# Real Server 1 configuration
# 指定了真實主機1的ip和端口
real_server 172.16.28.132 80 {

weight 1\t# 指定了當前主機的權重
TCP_CHECK {
connection_timeout 10\t# 指定了進行心跳檢查的超時時間
nb_get_retry 3\t# 指定了心跳超時之後的重複次數
delay_before_retry 3\t# 指定了在嘗試之前延遲多長時間
}
}
# Real Server 2 Configuration
real_server 172.16.28.133 80 {
weight 1\t# 指定了當前主機的權重
TCP_CHECK {
connection_timeout 10\t# 指定了進行心跳檢查的超時時間
nb_get_retry 3\t# 指定了心跳超時之後的重複次數
delay_before_retry 3\t# 指定了在嘗試之前延遲多長時間
}
}
}

上面是master節點上keepalived的配置,對於backup節點,其配置與master幾乎是一致的,只是其state和priority參數不同。如下是backup節點的完整配置:

# Global Configuration
global_defs {
lvs_id director2 # 指定lvs的id
}
# VRRP Configuration
vrrp_instance LVS {
state BACKUP\t# 指定當前節點為master節點
interface ens33\t# 這裡的ens33是網卡的名稱,通過ifconfig或者ip addr可以查看
virtual_router_id 51\t# 這裡指定的是虛擬路由id,master節點和backup節點需要指定一樣的

priority 150\t# 指定了當前節點的優先級,數值越大優先級越高,master節點要高於backup節點
advert_int 1\t# 指定發送VRRP通告的間隔,單位是秒
authentication {
auth_type PASS\t# 鑑權,默認通過
auth_pass 123456\t# 鑑權訪問密碼
}
virtual_ipaddress {
172.16.28.120\t# 指定了虛擬ip
}
}
# Virtual Server Configuration - for www server
# 後臺真實主機的配置
virtual_server 172.16.28.120 80 {
delay_loop 1\t# 健康檢查的時間間隔
lb_algo rr\t# 負載均衡策略,這裡是輪詢
lb_kind DR\t# 調度器類型,這裡是DR
persistence_time 1\t# 指定了持續將請求打到同一臺真實主機的時間長度
protocol TCP\t# 指定了訪問後臺真實主機的協議類型
# Real Server 1 configuration
# 指定了真實主機1的ip和端口
real_server 172.16.28.132 80 {
weight 1\t# 指定了當前主機的權重
TCP_CHECK {
connection_timeout 10\t# 指定了進行心跳檢查的超時時間
nb_get_retry 3\t# 指定了心跳超時之後的重複次數
delay_before_retry 3\t# 指定了在嘗試之前延遲多長時間
}
}
# Real Server 2 Configuration
real_server 172.16.28.133 80 {

weight 1\t# 指定了當前主機的權重
TCP_CHECK {
connection_timeout 10\t# 指定了進行心跳檢查的超時時間
nb_get_retry 3\t# 指定了心跳超時之後的重複次數
delay_before_retry 3\t# 指定了在嘗試之前延遲多長時間
}
}
}

將master和backup配置成完全一樣的原因是,在master宕機時,可以根據backup的配置進行服務的無縫切換。

Keepalived+LVS+nginx搭建nginx高可用集群

在lvs+keepalived機器配置完成之後,我們下面配置兩臺應用服務器的nginx配置。這裡我們是將nginx作為應用服務器,在其配置文件中配置返回狀態碼為200,並且會將當前主機的ip返回,如下是其配置:

worker_processes auto;
# pid /run/nginx.pid;
events {
worker_connections 786;
}
http {
server {
listen 80;
# 這裡是直接返回200狀態碼和一段文本
location / {
default_type text/html;
return 200 "Hello, Nginx! Server [email protected]\\n";
}
}
}
worker_processes auto;
# pid /run/nginx.pid;
events {
worker_connections 786;
}
http {
server {
listen 80;
# 這裡是直接返回200狀態碼和一段文本
location / {
default_type text/html;
return 200 "Hello, Nginx! Server [email protected]\\n";
}
}
}

可以看到,兩臺機器返回的文本中主機ip是不一樣的。nginx配置完成後,可以通過如下命令進行啟動:

sudo nginx

在啟動nginx之後,我們需要配置虛擬ip,這是因為我們使用的lvs調度器是DR模式,前面我們講到過,這種模式下,對客戶端的響應是真實服務器直接返回給客戶端的,而真實服務器需要將響應報文中的源ip修改為虛擬ip,這裡配置的虛擬ip就是起這個作用的。我們編輯/etc/init.d/lvsrs 文件,寫入如下內容:

#!/bin/bash
ifconfig lo:0 172.16.28.120 netmask 255.255.255.255 broadcast 172.16.28.120 up
route add -host 172.16.28.120 dev lo:0
echo "0" > /proc/sys/net/ipv4/ip_forward
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_ignore
echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce
exit 0
  • lo:表示當前主機真實網卡的名稱;
  • 172.16.28.120:表示虛擬ip;

編寫完成後運行該腳本文件即可。然後將兩臺lvs+keepalived機器上的keepalived服務啟動起來即可:

sudo service keepalived start

最後可以通過如下命令查看配置的lvs+keepalived的策略:

[zhangxufeng@localhost keepalived]$ sudo ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.16.28.120:80 rr
-> 172.16.28.132:80 Route 1 0 0

2.2 集群測試

根據上述步驟,我們配置完成了一個lvs+keepalived+nginx的集群。在瀏覽器中,我們可以訪問http://172.16.28.120 即可看到如下響應:

Hello, Nginx! Server [email protected]

多次刷新瀏覽器之後,可以看到瀏覽器中顯示的文本切換如下,這是因為lvs的負載均衡策略產生的:

Hello, Nginx! Server [email protected]

3. 小結

本文首先對lvs和keepalived的工作原理進行了講解,分別介紹了其工作的幾種模式,然後對lvs+keepalived+nginx搭建nginx集群的方式進行詳細講解,並且說明了其中所需要注意的問題。


分享到:


相關文章: