【EOShenzhen】基於LVS的高可用架構（第一篇）

版權聲明：

以下內容來自微信公共帳號“EOS技術愛好者”，搜索“EOSTechLover”即可訂閱，本文作者Brandon Lu ，協同：Sheldon。轉載必須保留以上聲明。僅授權原文轉載。

---

1.LVS 的模式

我們先分析實現虛擬網絡服務的主要技術，指出IP負載均衡技術是在負載調度器的實現技術中效率最高的。LVS實現了3種IP負載均衡技術（LVS/NAT、LVS/DR和LVS/TUN）。

本文主要描述這3種技術的原理，以及它們各自的優缺點。

1.1 LVS/NAT（Network Address Translation）網路地址轉換

基于LVS的高可用架构.png

-用戶通過VIP訪問網絡服務時，請求先達到LB (調度器)；

• 調度器根據連接調度算法從一組真實服務器中選出一台服務器，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將修改後的報文發送給選出的服務器。

• 調度器在連接Hash表中記錄這個連接，當這個連接的下一個報文到達時，從連接Hash表中可以得到原選定服務器的地址和端口，進行同樣的改寫操作，並將報文傳給原選定的服務器；

• 後端的webserver 處理請求包，並返回數據包給調度器；

• 當來自真實服務器的響應報文經過調度器時，調度器將報文的源地址和源端口改為Virtual IP Address和相應的端口，再把報文發給用戶。

NAT模式的特點是：

• 後端RS不需要外網IP，數據在內網環境完成交互；

• 一個LB承載的RealServer數量有限，LB容易成為整個web 集群的瓶頸。

1.2 DR (Direct Routing) 直接路由模式

基于LVS的高可用架构2.png

DR模式

它的連接調度和管理與LVS/NAT中的一樣，它的報文轉發方法又有不同，將報文直接路由給目標服務器。

• LB和RS都使用同一個IP對外服務，必須在一個廣播域/交換機上｡

• 但只有DR對ARP請求進行響應,所有RS對本身這個IP的ARP請求保持靜默｡

• 網關會把對這個服務IP的請求全部定向給DR,而DR收到數據包後根據調度算法,找出對應的RS,把目的MAC地址改為RS的MAC（因為IP一致）並將請求分發給這台RS｡

• 這時RS收到這個數據包,處理完成之後，由於IP一致，可以直接將數據返給客戶，則等於直接從客戶端收到這個數據包無異,處理後直接返回給客戶端｡

DR模式的特點在於：

• LB與Realserver必須在物理上有一個網卡通過不間斷的局域網相連，RealServer上綁定的VIP配置在各自Non-ARP的網絡設備上(如lo或tunl)，LB的VIP地址對外可見；

• DR模式下，請求報文必須經過LB調度，響應報文不經過LB，而是直接轉發給用戶；

• 解決了NAT模式下的轉發瓶頸問題，能夠支撐更大規模的負載均衡場景；

• 比較耗費外網IP資源，在生產環境中，可以採用DR/NAT混合模式來緩解這個問題。

1.3 LVS Tunnel (IP Tunnel)隧道模式

基于LVS的高可用架构3.png

原理：

其實TUN模式跟DR模式的數據流走向類似，但是兩種方式的工作原理、應用場景完全不一樣。DR模式基於數據報文重寫（mac修改）；TUN基於IP Tunnel(IP 隧道)，是數據包的重新封裝。

VS/TUN的工作流程如圖3所示：

• 它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同；

• 調度器根據各個服務器的負載情況，動態地選擇一台服務器， 將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；

• 服務器收到報文後，先將報文解封獲得原來目標地址為VIP的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。

適用場景：

在生產環境中由於業務需要、技術需要或者安全需要，可能使用交換機進行VLAN隔離（即形成若干個虛擬的獨立的局域網），我們可能需要LVS節點在局域網A，而需要進行負載的多台web(或mysql)服務器可能在局域網B中，這個時候就需要用到LVS-TUN模式了

總結：

LVS在誕生初期就是為了高可用、可彈性伸縮的網絡服務而設計，三種調度方式都是基於IP層做的負載均衡。LVS的優點是高性能、高可用、可伸縮性，現在已成linux 標準內核裡面的一部分（kernel 2.4.24以後），用LVS應對高流量的業務場景是非常合適，而且性價比高。

結合當前的業務情況，我們生產環境選擇用LVS-NAT模式，主要基於以下原因：

IP資源開銷小；

後端的fullnode 服務節點不暴露公網IP，提升整體的安全性。

2.Keepalived 功能

VRRP協議為keepalived實現基礎的

虛擬路由冗餘協議，可以認為是實現路由器高可用的協議，即將N台提供相同功能的路由器組成一個路由器組，這個組裡面有一個master和多個backup，

• master上面有一個對外提供服務的vip（該路由器所在局域網內其他機器的默認路由為該vip），master會發組播，當backup收不到vrrp包時就認為master宕掉了

• 這時就需要根據VRRP的優先級來選舉一個backup當master。這樣的話就可以保證路由器的高可用了。

keepalived主要有三個模塊，Core、Check和VRRP

• core：主進程的啟動、維護以及全局配置文件的加載和解析

-用於監控LVS 各個服務節點的狀態

• check：健康檢查

• vrrp：實現VRRP協議(虛擬路由冗餘協議)

VRRP：保證不間斷運行，用最快的速度接管服務

防火牆一定要開啟vrrp協議的支持

用於監控LVS 各個服務節點的狀態

雙主配置

Keepalived配置文件keepalived.conf的默認位置是/etc/keepalived

global_defs {
    router_id sz_proxy_fn1
}
vrrp_instance VI_2 {
    state BACKUP
    interface eth0
    virtual_router_id 55
    priority 99
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass proxyfn2
    }
     virtual_ipaddress {
        120.197.130.119 dev enp3s0f1 label enp3s0f1:vip
    }
}

其中router_id 中master必須和slave一隻

advert_int 代表心跳檢測

virtual_router_id 代表虛擬路由id

keepalived 用於VIP的快速切換，可以實現LB的主備，在服務器出現宕機或者維護的時候，可以迅速把流量導向備節點。目前對外的服務都會採用LVS+keepalived 的方式組成成對的LB調度器，以提供業務的持續服務能力。

3.Nginx VS HAproxy

介紹完了調度器之後，我們重點分析以下nginx /haproxy 在作為後端web server方面各自有的特點。隨著互聯網的快速發展，web類的服務越來越多，而且業務邏輯也非常複雜，並發能力已經不是考量一個web類服務的唯一指標， 更多的時候我們需要考量業務本身的需求。

這個時候就需要一個性能強大、配置靈活、支持第三方擴展、監控、訪問日誌審計等綜合需求的web中間件。我們主要來比較nginx和haproxy作為webserver各自的特點。

nginx特點：

• nginx 對網絡穩定性的依賴性較小，理論上只要ping得通，網頁就能打得開；

• nginx工作在網絡的第七層，側重點在web服務器，可以針對Http應用做一些分流的策略，如域名、目錄結構。nginx支持的協議類型有：HTTP/TCP/GRPC等，

• nginx有眾多第三方模塊，作為web 應用服務器，可以利用第三方模塊靈活擴展，比如lua，應用可以根據場景，在nginx層完成邏輯處理；nginx自身的狀態檢測，比如nginx-module-vts等；

• 在靜態文件處理上，加location可以靈活配置，比如重定向到CDN，或者緩存服務器等；

• nginx在轉發效率高，專為性能優化而開發；支持epoll模型，能經受高並發的考驗，優化後的理論並發可以達到幾萬

haproxy 特點：

• haproxy 可以工作在第四、七層，在web類應用中，配置策略沒有nginx靈活，比如目錄層次，https證書配置等。

• haproxy 的角色定位其實是一個LB(load blance)，是一款負載均衡軟件，也支持很多負載均衡策略，比如：roundrobin/static-rr/source等。

總結：

http/https等web類服務，我們可以根據應用的複雜度，用戶場景等方面具體考量用哪種webserver，目前EOShenzhen已經在接口類服務會採用haproxy作轉發器，haproxy在轉發效率和並發能力上是優於nginx的，而且支持的負載均衡策略非常多；

網站類服務（包括https）會採用LVS+nginx的方案，靈活配置，支持熱重啟等。特別是https 可以藉助於intel QAT 加速卡+nginx第三方擴展來完成加解密的過程，極大提升nginx 對https的支撐性能。

EOShenzhen已經構建了成熟的LB集群、Web server集群，並會持續投入更多的資源，用一流的技術能力，來為開發者提供強有力的接入支撐。

本文圖片由EOShenzhen製作，轉載請聲明

---

本原創文章作者: Brandon Lu ，協同: Sheldon ，首發於微信公眾號“EOS技術愛好者”。轉載請參照本文文首說明。

關於EOShenzhen，了解更多可點擊：We are EOShenzhen（EOS區塊生產者競選人）

關於我們更多聯繫：

Website：https://eoshenzhen.io

Steem：https://steemit.com/@eoshenzhen

Busy：https://busy.org/@eoshenzhen

Telegram：https://t.me/eoshenzhen

Twitter：https://twitter.com/eostechlover

簡書：EOS技術愛好者

新浪微博：EOSTechLover

---

EOShenzhen的超级节点账户是eoshenzhenio；
1、使用命令行投票
cleos --wallet-url http://localhost:8900 --url http://mainnet.libertyblock.io:8888 system voteproducer prods <您的账户> eoshenzhenio
（注：你可以把http://mainnet.libertyblock.io:8888全节点改您信任的fullnode）

2、使用目前社区公认的网站投票: http://eosportal.io
文字教程
視頻教程（需要科學上網）