來源 | 故事凌
責編 | Carol
封圖 | CSDN 下載於視覺中國
昨天我們講到《那些你不知道的 LVS 秘密》，今天我們就繼續一起來進行 LVS 更深的探索，來一起通關 LVS+Keepalived吧！
keepalived
keepalive的學習參考網站：https://www.keepalived.org/
在學習keepalived之前, 我們來思考一個問題：LVS只是負責負載均衡的轉發，那如果後臺的Real Server的服務掛掉以後，LVS是否能主動把這個摘除掉嗎？答案是：肯定不行的，就是LVS不具備把後端掛掉的Real Server摘除掉，所以keepalived的應用而生。
keepalived 起初就是為LVS設計的，專門用來監控集群系統中各個服務節點的狀態，它根據tcp/ip參考模型的第三四和第五層交換機制檢測每個服務節點的狀態，每個服務節點異常或者工作障礙，keepalvied講立刻檢測到，並把障礙節點剔除，是毫秒級的，當後臺節點恢復正常以後，keepalived有自動將服務節點重新添加在服務器集群中。
keepalvied後來又加了vrrp功能，vrrp（虛擬路由器冗餘協議），出現的目的就是解決靜態路由單點故障的問題，通過vrrp可以實現網絡不間斷穩定運行。
keepalived簡介
1、什麼是Keepalived？
Keepalived是用C語言編寫的路由軟件。該項目的主要目標是為Linux系統和基於Linux的基礎結構提供負載均衡和高可用性的簡單而強大的功能。負載平衡框架依賴於提供第4層負載平衡的著名且廣泛使用的Linux虛擬服務器（IPVS）內核模塊。Keepalived實現了一組VIP功能，以根據其運行狀況動態，自適應地維護和管理負載平衡的服務器池。
另一方面，VRRP實現了高可用性 協議。VRRP是路由器故障轉移的基礎。此外，Keepalived還實現了一組VRRP有限狀態機的掛鉤，從而提供了低級和高速協議交互。為了提供最快的網絡故障檢測，Keepalived實施BFD協議。VRRP狀態轉換可以考慮BFD提示來驅動快速狀態轉換。Keepalived框架可以獨立使用，也可以一起使用以提供彈性基礎架構。
keepalived支持多組VIP的操作，就是一臺服務器上可以部署多臺VIP，可以理解為每個VIP是一組操作。
2、keepalived的主從切換
相信你們也看到過一張圖片，圖中有兩張桌子，左邊的桌子上有一張桌布，在不一移動桌面物品的情況下將桌布換到了右邊的桌子。
這兩個桌子就是我們的兩個服務器，桌布就是我們的VIP，如果心跳檢查發現兩個服務器之間有問題, 會主動切換到從服務器上，時間也是毫秒級別的。
3、keepalive的使用場景
可以說，keepalived本身就是給LVS量身定做的，LVS雖然是可以進行負載均衡的請求的轉發，如果後端服務器檢查到服務器故障，LVS是可以主動切除的，這個LVS本身具備的功能，而且切除後端Real Server的時間都是在毫秒級別，特別的快速，畢竟LVS已經集成到Linux系統內核了。那就有一個問題, 如果LVS服務器掛掉了呢?我們的服務是不是就不可用了呢？那就來看看我們keepalived的使用場景了。
- LVS和keepalived可以說是天然的集成, 我們在linux系統安裝的時候, 可能都不需要什麼特殊的LVS的配置, lvs+keepalived的集成, 只需要在keepalived的配置文件中增加配置就ok
- keepalive提供了主從切換的功能, 主從之間有心跳檢測, 如果發現主從掛掉, keepalived會自動進行主從的切換
- 單體架構中, 我們最常使用lvs+keepalived的功能'
keepalivd的工作原理
1、架構原理
- 分為兩大層：內核空間(Kernel Space)、用戶空間(User Space)
- IPVS(IP Virtual Server): 實現傳輸層負載平衡，也稱為第4層交換；
- NETLINK: 用於在內核和用戶空間進程之間傳輸信息；
Keepalived 分為3個守護進程：
- 父進程: 很簡單，負責 fork 子進程，並監視子進程健康狀態(圖中 WatchDog 週期性發送檢測包，需要的話重啟子進程)；
- 子進程A: 負責VRRP框架(圖中 VRRP Stack)
- 子進程B: 負責健康檢查(圖中 Checkers)
2、運行原理
keepalived 通過選舉（看服務器設置的權重）挑選出一臺熱備服務器做 MASTER 機器，MASTER 機器會被分配到一個指定的虛擬 ip，即VIP, 外部程序可通過該 VIP 訪問這臺服務器，如果這臺服務器出現故障（斷網，重啟，或者本機器上的 keepalived crash 等），keepalived 會從其他的備份機器上重選（還是看服務器設置的權重）一臺機器做 MASTER 並分配同樣的虛擬 IP，充當前一臺 MASTER 的角色。權重越高，備用機器被拉起來的佔比就越大，一般的主備就可以滿足我們的需求。
3、選舉策略
選舉策略是根據 VRRP 協議，完全按照權重大小，權重最大的是 MASTER 機器，下面幾種情況會觸發選舉
- keepalived 啟動的時候
- master 服務器出現故障（斷網，重啟，或者本機器上的 keepalived crash 等，而本機器上其他應用程序 crash 不算）
- 有新的備份服務器加入且權重最大
keepalived的腦裂
1、什麼是腦裂
在高可用系統中，作為主備節點的兩臺服務器，可能因為一些比如說網絡斷開，兩臺機器的心跳檢測會認為主掛了，但是主其實是正常的，只是網絡斷開了，心跳檢測沒法檢查到主還活著，由於主從之間失去了聯繫，都以為是對方發生了故障，所以兩個節點都會主動的搶佔資源，爭搶應用服務，爭搶VIP，這樣就發發生一些嚴重的後果，或者資源被瓜分了、或者是兩邊的節點都啟動不起來了、或者是都起來了，但是同時讀寫共享存儲，導致數據損壞。
2、腦裂產生的原因
- 高可用服務器對之間心跳線鏈路發生故障，導致無法正常通信
- 因心跳線斷開（包括網線斷裂、水晶頭鬆動等物理原因）
- 因網卡及相關驅動壞了，ip配置及衝突問題（網卡直連）
- 因心跳線間連接的設備故障（網卡及交換機）
- 因仲裁的機器出問題（採用仲裁的方案）
- 高可用服務器上開啟了 iptables防火牆阻擋了心跳消息傳輸
- 高可用服務器上心跳網卡地址等信息配置不正確，導致發送心跳失敗
- 其他服務配置不當等原因，如心跳方式不同，心跳廣插衝突、軟件Bug等
3、腦裂常見的解決方案
在實際生產環境中，我們可以從以下幾個方面來防止裂腦問題的發生：
- 同時使用串行電纜和以太網電纜連接，同時用兩條心跳線路，這樣一條線路壞了，另一個還是好的，依然能傳送心跳消息
- 當檢測到裂腦時強行關閉一個心跳節點（這個功能需特殊設備支持，如Stonith、feyce）。相當於備節點接收不到心跳消患，通過單獨的線路發送關機命令關閉主節點的電源
- 做好對裂腦的監控報警（如郵件及手機短信等或值班）.在問題發生時人為第一時間介入仲裁，降低損失。例如，百度的監控報警短倍就有上行和下行的區別。報警消息發送到管理員手機上，管理員可以通過手機回覆對應數字或簡單的字符串操作返回給服務器.讓服務器根據指令自動處理相應故障，這樣解決故障的時間更短.
當然，在實施高可用方案時，要根據業務實際需求確定是否能容忍這樣的損失。對於一般的網站常規業務。這個損失是可容忍的。
lvs+keepalived
lvs和keepalived應該可以說是天然的集成, 在因為LVS已經集成到linux內核系統中, 我們只需要配置一下keepalived的配置文件就可以了, 那我們還是主要來研究一下keepalived的配置文件, 就可以輕鬆的使用了
1、keepalived的配置文件
<code>#全局配置global_defs { notification_email { #設置報警郵件地址，每行一個，（如何要開啟郵件報警，需要開啟本機的sendmail服務） [email protected] } notification_email_from [email protected] #設置郵件的發送地址 smtp_server smtp.qq.com #設置郵件的smtp server地址 smtp_connect_timeout 30 #設置連接smtp server的超時時間 router_id LVS_DEVEL #表示keepalived服務器的一個標識，是發郵件時顯示在郵件主題中的信息}#keepalived的VRRPD配置，是所有keepalived配置的核心#VRRP實例配置vrrp_instance VIP_142 #是VRRP實例開始的標識，後跟VRRP實例名稱{state MASTER #keepalived的角色，MASTER主，BACKUP備interface eth0 #用於指定HA監測網絡的接口virtual_router_id 142 #虛擬路由標識，這個標識是一個數字，同一個VRRP實例使用唯一的一個標識，即在同一個vrrp_instance下，MASTER和BACKUP必須是一致的！priority 100 #權重優先級advert_int 2 #用於設定master和backup主機之間同步檢查的時間間隔，單位是秒garp_master_delay 10 #用於切換到master狀態後延時進行Gratuitous arp請求的時間smtp_alert #表示是否開啟郵件通知(用全局區域的郵件設置來發通知)authentication #主備之間進行通信的驗證類型和密碼：驗證類型主要有PASS和AH兩種，一個在vrrp_instance下，MASTER和backup必須使用相同的密碼才可以通信{auth_type PASSauth_pass 123456}#virtual_ipaddress用於設置虛擬ip地址，可以設置多個vip，每行一個，virtual_ipaddress{10.95.0.200/24}track_interface #用於設置一些額外的網絡監控接口，其中任何一個網絡接口出現故障，keepalived都會進去fault狀態！{eth0}nopreempt #設置不搶佔功能，只能在backup上使用，知道機器有故障了才切換，preemtp_delay 300 #用於設置搶佔的延時時間，（例：開啟啟動沒必要搶佔）}#以下是lvs的主要主要配置信息，主要實現lvs的ip包轉發功能！virtual_server 10.95.0.200 80 #虛擬ip和端口{delay_loop 6 #設置健康檢查的時間間隔lb_algo wrr #設置負載調度算法lb_kind DR #設置lvs的模式persistence_timeout 60 #會話保持時間，單位秒protocol TCP #ip包轉發協議，有TCP和UDP兩種real_server 10.95.0.143 80 #real server 的ip{ weight 3 #權重 TCP_CHECK #健康檢查 { connect_timeout 10 #表示無響應超時時間 nb_get_retry 3 #表示重連次數 delay_before_retry 3 #表示重試間隔 connect_port 80 #表示端口 }}real_server 10.95.0.144 80{ weight 3 TCP_CHECK { connect_timeout 10 nb_get_retry 3 delay_before_retry 3 connect_port 80 }}}2、keepalived的心跳檢測/<code> 健康監測應許多種檢查方式，常見的有，HTTP_GET，SSL_GET，TCP_CHECK，SMTP_CHECK，MISC_CHECK.
<code>TCP_CHECK { conetct_port 80 connect_timeout 3 nb_get_retry 3 delay_before_retry 3}connect_port:健康檢查的端口，如果不指定，默認是real_server指定的端口connect_timeout:表示無響應超時時間，單位是秒，這裡是3snb_get_retry：表示重試次數，這裡是3cidelay_before_retry：表示重試間隔，HTTP_GET |SSL_GET{ url{ path /index.html #指定url信息 digest e6owjfdsjfalsjdfsalkf30wfdsfjwqe #ssl檢查後的摘要信息，這些摘要信息可以通過genhash命令工具獲取， #例：genhash -s 192.168.12.80 -p 80 -u /index.html status_code 200 } connect_port 80 bindto 192.168.31.128 #表示通過此地址來對發送請求對服務器進行健康檢查 nb_get_retry 3 delay_before_retry 2}/<code>
LVS+keepalvied使用過程的一些坑
1. keepalived的啟動
在配置keepalived.conf的配置文件時，一定要檢查配置文件的正確性，因為keepalived在重啟時，並不檢查配置文件的正確性，即使沒有配置文件，keepalived照樣可以啟動，所以一定要檢查配置文件是否正確
2. keepalived服務器的侷限性
下面LVS+DR+keepalived+nginx+tomcat的一個架構
在我們的工作中，如果要是實現上面的方案，應用服務器的個數應該有8臺服務器，但是我們發現問題，如果keepalvied的VIP在主上的時候，keepalived的從服務器上是沒有任何請求的，幾乎沒有什麼壓力，只有發生VIP偏移，從才會進行工作，那為了提高服務器的使用率，keepalived的服務器是否可以作為tomcat服務器來使用呢？如果用了，那就掉坑裡面了。下面我們來說說原因。
上圖中的keepalived服務器，nginx服務器，都是有綁定VIP的，如果不清楚LVS的DR模式，可以上看文首那一篇的LVS的文章。
我們如果在nginx服務器上部署tomat應用，好的，就是把nginx也當成是tomcat服務器，這個可以為我們節省一些資源，但是如果你把tomcat部署在keepalived服務器上，你真的就有坑了。
如果在lvs+keepalvied(主)服務器上部署了tomcat應用，不可避免的，我們應用中有調用域名或者VIP的函數或者方法，即服務之間的相互調用，應用在發起請求的時候，它的源ip地址就可以是VIP地址，目標IP地址是VIP，這個時候請求是可以正常轉發，處理的，但是最後nginx處理完請求以後， nginx就懵逼了，她沒法把請求返回給lvs+keepalvied(主)服務器的請求，這時候的nginx太難了，nginx是Real Service，DR模式中，他自己是有VIP的，他自己是vip，讓他返回給VIP， 你是nginx，你也懵逼。
總之一句話總結: LVS+keepalived服務器上不能部署發起請求的客戶端應用, 否則接收不到消息。
3. 主故障恢復, 避免自動切換
背景需求：在一個HA集群中，如果主節點死機了，備用節點會進行接管，主節點再次正常啟動後一般會自動接管服務。對於實時性和穩定性要求不高的的業務系統來說，這種來回切換的操作是可以接受的。而對於穩定性和實時性要求很高的業務系統來說，不建議來回切換，畢竟服務的切換存在一定的風險和不穩定性。
方法一：
在這種情況下，就需要設置nopreempt這個選項，設置mopreempt可以實現主節點故障恢復後不再切換回主節點，讓服務器一直在備節點下工作，知道備用節點出現故障才會進行切換，在使用不搶佔功能時，只能在“state”狀態為“BACKUP”的節點上設置，而且這個節點的優先級必須高於其他節點。
方法二：角色可以都設為BACKUP 權重一樣 先啟動一個節點 後面的故障切換誰搶到誰用
LVS的集群模式
我們用流量的併發來進行計算，如果流量是10w以下的併發，那我們可能使用nginx+keepalived的架構，可能就直接可以滿足需求，那如果請求幾十萬的併發的，那就推薦大家使用lvs+keepalived的架構，這個lvs的併發，一個配置不錯的應用服務器，應該可以扛個幾十萬的併發，是沒有問題，那如果請求量還是很大的, lvs扛不住， 把我的機器打崩了呢，那這個時候LVS集群模式就誕生了。其實就是一個思路，請求大了機器來扛。
fullnat是淘寶開源的一種lvs轉發模式，主要思想：引入local address（內網ip地址），cip-vip轉換為lip->rip，而 lip和rip均為IDC內網ip，可以跨vlan通訊，這剛好符合我們的需求，因為我們的內網是劃分了vlan的。
首先我們在瞭解這種方式之前, 我們來了解一下什麼是OSPF?
1、什麼是OSPF?
OSPF(Open Shortest Path First開放式最短路徑優先）是一個內部網關協議(Interior Gateway Protocol，簡稱IGP），用於在單一自治系統（autonomous system,AS）內決策路由。是對鏈路狀態路由協議的一種實現，隸屬內部網關協議（IGP），故運作於自治系統內部。著名的迪克斯加算法被用來計算最短路徑樹。OSPF支持負載均衡和基於服務類型的選路，也支持多種路由形式，如特定主機路由和子網路由等。
我們通過OSPF在服務上安裝, 實現路由到LVS服務器上的最短路徑是一樣的, 從而實現LVS平均接收請求, 可以接受更高的併發量.
這個時候可能需要網絡的同事幫我們配置一下了, 在路由器上需要進行一些設置
2、架構圖
作者：凌晶
生活中的段子手，目前就職於一家地產公司做 DevOPS 相關工作, 曾在大型互聯網公司做高級運維工程師，熟悉 Linux 運維，Python 運維開發，Java 開發，DevOPS 常用開發組件等
