一、背景

專案背景是某企業的AAA管理系統， AAA 即 Authentication（認證）、Authorization（授權）、Accounting（記賬），是網路裝置的一種集中化管理機制，可以在不同裝置上為使用者設定不同的許可權，對網路安全起到監視作用。

AAA服務是基於TACACS+協議（Terminal Access Controller Access Control System Plus），TACACS＋是在 TACACS 協議的基礎上進行了功能增強的安全協議，最早由Cicso提出並開放標準。該協議與 RADIUS 協議的功能類似，採用客戶端/伺服器模式實現 網元與 TACACS+ 伺服器之間的通訊，使用TCP 49埠。

每次TACACS+ 互動主要實現： 認證 (Authentication): 確認訪問網路的使用者身份，判斷訪問者是否合法 授權( Authorization ): 對通過認證的使用者，授權其可以使用哪些服務 記賬( Accounting )：記錄使用者的操作行為、發生時間

1.問題描述

系統架構如下圖所示，伺服器採用一主一備模式，一般情況下由Master伺服器處理請求，如果它故障或者負荷過高、無法快速響應請求，網元會將請求傳送到BackUP伺服器處理。AAA Server上執行守護程序處理請求，記為TACACSD。

容量計算

在很長一段時間內，原有架構可以滿足應用需求，但是隨著集中化的深入推進，資源不足的問題日益嚴重：Master負荷早已爆滿，BackUP的負荷也幾乎與Master相當，而且請求從Master切換到BackUP的時候，非常容易引起失敗。 主要有三個關鍵因子的變化： 1、管理裝置數量增長10倍，而且還要繼續增長 2、網路配置自動化，單一網元的巡檢、配置操作有數量級的提升
3、TACACSD程式本身存在效能瓶頸，CPU消耗隨著裝置數量增長而增長

前兩個因素屬於業務需求，不能調整，程式效能問題涉及開發週期問題（這塊以後再單獨分析），迫於業務壓力，我們必須快速尋找一種變通方案。

2.選型要求

在選擇適用方案之前，我們必須考慮以下幾個要求：

可伸縮性（Scalability） 當服務規模（裝置數量、自動化操作次數）的負載增長時，系統能被擴充套件來滿足需求（彈性擴充套件服務能力），且不降低服務質量。

高可用性（Availability） 儘管部分硬體和軟體會發生故障，整個系統的服務必須是每天24小時每星期7天可用的。（必須去除原來過於依賴單一伺服器的瓶頸）

可管理性（Manageability） 整個實現應該易於管理，提供靈活的負載均衡策略支援。

價格有效性（Cost-effectiveness） 整個實現是經濟的。這個怎麼說呢，比如這個問題吧，有人說：買四層交換機啊？ 沒錢！宇宙上最好伺服器來一臺？ 沒錢！！ 於是我們的主要探索方向放在了開源軟體，感謝開源社群解救窮人。

二、前戲

我們首先想到的是HAProxy，一款經典的負載均衡開源軟體。 特別是具備以下幾個特點：配置維護簡單，支援熱備，支援後端伺服器的狀態檢測，可以自動摘除故障伺服器；支援TCP 代理；支援Session的保持。

tcp
The instance will work in pure TCP mode. A full-duplex connection will be established between clients and servers, and no layer 7 examination will be performed. This is the default mode. It should be used for SSL, SSH, SMTP, …

1.HAProxy+TProxy

當我們滿懷希望地推進之時，一個要命的問題擺在面前：後端的AAA伺服器上看到的連線的Source IP都不再是使用者原始的IP，而是前端的HAProxy伺服器的IP，

官方文件對於source排程演算法的描述：

source
The source IP address is hashed and divided by the total weight of the > running servers to designate which server will receive the request. This ensures that the same client IP address will always reach the same server as long as no server goes down or up. If the hash result changes due to the number of running servers changing, many clients will be directed to a different server.

TACACSD程序必須獲取到認證請求的Source IP，為此我們嘗試引入TProxy。 它允許你”模仿”使用者的訪問IP，就像負載均衡裝置不存在一樣，TProxy名字中的T表示的就是transparent(透明)。當網元發起的認證請求到達後端的AAA伺服器時，可以通過抓包看到的請求Source IP就是網元的真實IP。

即使用上“HAProxy+TProxy”的組合拳，還是存在另外一個問題： 裝置對於認證結果報文，似乎需要請求報文的目標地址（代理伺服器）與結果報文的傳送端（Real AAA Server）一致。

過程描述：網路裝置會發送該使用者的憑證到 TACACS+ 伺服器進行驗證，然後決定分配訪問相關裝置的許可權，並將這些決定的結果包含在應答資料包中併發送到網路裝置上，再由網路裝置傳送到使用者終端。 至於是否真的是這個校驗規則，或者我們還沒有找到更好的解釋。暫且擱置，引述一段RFC 1492的說明，日後再補充這個問題。CONNECT(username, password, line, destinationIP, destinationPort) returns (result1, result2, result3)

This request can only be issued when the username and line specify an already-existing connection. As such, no authentication is required and the password will in general be the empty string. It asks, in the context of that connection, whether a TCP connection can be opened to the specified destination IP address and port.

2.IPTABLES NAT

為了解決上述Proxy無法傳遞Source IP 的問題，我們還嘗試過基於 iptables 實現網路地址轉換的方式，It’s Working !!

如上即可解決HAProxy的Source IP 傳遞和報文迴路的問題。 壓力測試的時候，開始裝置數比較少的時候，各項業務還很正常，當裝置數加到1.5萬臺左右，或者幾百臺裝置併發請求的時候，報文轉發的時延久急劇上升，甚至出現丟包情況。這個方案對我們來說顯然存在效能瓶頸。

HAProxy—>HAProxy + TProxy —>IPTABLES NAT

轉了一圈，回到起點。

三、終極殺器

經過之前一波三折的折騰，我們決定啟用一款終極殺器：LVS。 LVS即Linux Virtual Server，是一個虛擬的伺服器集群系統。它有三種工作模式NAT(地址轉換),IP Tunneling(IP隧道)、Direct Routing(直接路由)。

基於之前NAT方面的不良體驗，我們這次直接選擇了LVS-DR模式， LVS支援八種排程演算法，我們選擇輪詢排程（Round-Robin Scheduling）。

LVS只處理一般連線,將請求給後端real server,然後由real server處理請求直接相應給使用者,Direct Routing與IP Tunneling相比，沒有IP封裝的開銷。

缺點：由於採用物理層,所以DR模式的排程器和後端real server必須在一個物理網段裡,中間不能過路由器。

另外，為了防止LVS控制機的單點故障問題，還選用了Keepalived，負責LVS控制機和備用機的自動故障切換。

LVS依賴項：IPVS核心模組和ipvsadm工具包。 具體配置不做過多說明，可以自行檢索，關鍵注意以下幾點： 1）檢查伺服器是否已支援ipvs modprobe -l |grep itvs 2）檢查依賴包： rpm -q kernel-devel rpm -q gcc rpm -q openssl rpm -q openssl-devel rpm -q popt 3）配置realserver節點ARP及VIP繫結指令碼 vi /etc/init.d/lvs 4）啟動LVS-DR /etc/init.d/lvsdr start 5）檢視VIP 情況 ip addr list 6）啟動realserver節點LVS /etc/init.d/lvs start

五、小結

1. 各種負載均衡實現在網路中的位置

四層負載均衡的特點一般是在網路和網路傳輸層(TCP/IP)做負載均衡，而七層則是指在應用層做負載均衡。 四層負載均衡對於應用侵入比較小，對應用的感知較也少，同時應用接入基本不需要對此做特殊改造。 七層負載均衡一般對應用本身的感知比較多，可以結合一些通用的業務負載邏輯做成很細緻的方案，比如我們通常用HAProxy/Nginx來做網站流量的分發。

實踐再次教育我們，天下沒有一招鮮，任何技術都有它的江湖位置。

2. 模擬能力

這次實踐可以用一句話概括就是：“成也模擬，敗也模擬”。 起初走了很長一段彎路，可以說是因為對整個負載均衡體系的理解不深入，也可以說是測試不足導致，憑著慣性，想當然地認為可以簡單複製原來的“經驗”，而 忽視了實驗環境的構建。

後來可以快速推進，是因為重新規整了測試方法和目標，並且基於虛擬機器搭建了驗證環境，包括引入了可以模擬路由器的GNS3平臺，完整地測試了真實的業務流程。LVS叢集環境也是先完成構建、試執行一段時間之後才完成的業務割接。

IPTABLES NAT的方案並沒有在早期發現效能瓶頸，也說明這快的測試能力不足。

3.花邊故事

HAProxy的官網目前是被封鎖的，國內沒梯子訪問不了，Why ? 在他們家的操作手冊後面有LVS、Nginx的推薦連結。以前並沒有注意。

TPROXY最早是作為Linux核心的一個patch，從linux-2.6.28以後TPRXOY已經進入官方核心。iptables只是Linux防火牆的管理工具而已，位於/sbin/iptables。真正實現防火牆功能的是Netfilter，它是Linux核心中實現包過濾，如果要探討Netfilter，又會是一個很長的故事。

LVS開始於1998年，創始人是章文嵩博士，從Linux2.4核心以後，已經完全內建了LVS的各個功能模組。到今天為止，依然是目前國內IT業界達到Linux標準核心模組層面的唯一碩果。章博士同時是前淘寶基礎軟體研發負責人、前阿里雲CTO，三個月前剛轉會到滴滴打車任副總裁。淘寶技術體系曾大規模使用了LVS，不過最新訊息，淘寶的同學已經鼓搗出一個VIPServer，正逐步替代了LVS。

羅列的這幾條資訊，其實與這次的主題關係不大，但確是整理這次篇帖子過程中，感覺很有意思的事情。技術並不冰冷，它就像個江湖，到底還是關於人的故事。

續集

1、本次場景中， HAProxy方案為什麼會失敗？還缺少一個深度解釋。 2、本次場景中，LVS方案採用預設的輪詢演算法是否最優？ 3、本次場景中，7X24系統如何完成服務切換？ 4、本次場景中， IPTables NAT 的效能瓶頸如何解釋？ 5、來一個關於Netfilter的討論 6、閱讀參考資料 VIPServer: A System for Dynamic Address Mapping and Environment Management