Keepalived高可用集羣應用實踐

時間  2019-11-10
標籤 keepalived 可用 集羣 應用 實踐 欄目 負載均衡 简体版
原文   原文鏈接

1、Keepalived高可用軟件

1 Keepalived介紹 
Keepalived軟件起初是專門爲LVS負載均衡軟件設計的，用來管理並監控LVS集羣系統中各個服務節點的狀態，後來又加入了能夠實現高可用的VRRP功能。所以，Keepalived除了可以管理LVS軟件外，還能夠做爲其餘服務（例如：Nginx，Haproxy，MySQL等）的高可用解決方案軟件。 
Keepalived軟件主要是經過VRRP協議實現高可用功能的。VRRP是Virtual Router Redundancy Protocol（虛擬路由器冗餘協議）的縮寫，VRRP出現的目的就是爲了解決靜態路由單點故障問題的，他可以保證當個別節點宕機時，整個網絡能夠不間斷地運行。因此，Keepalived一方面具備配置管理LVS的功能，同時還具備對LVS下面節點進行健康檢查的功能，另外一方面也可實現系統網絡服務的高可用功能。 
Keepalived軟件的官方站點是http://www.keepalived.org前端

2 Keepalived服務的三個重要功能 
（1）管理LVS負載均衡軟件 
早期的LVS軟件，須要經過命令行或腳本實現管理，而且沒有針對LVS節點的健康檢查功能。爲了解決LVS的這些使用不便問題，Keepalived誕生了，能夠說，Keepalived軟件起初是專爲解決LVS的問題而誕生的。所以，Keepalived和LVS的感情很深，他們的關係如同夫妻同樣，能夠緊密地結合，愉快地工做。Keepalived能夠經過讀取自身的配置文件，實現經過更底層的接口直接管理LVS的配置以及控制服務的啓動，中止功能，這使得LVS的應用更加簡單方便了。 
（2）實現對LVS集羣節點健康檢查功能（healthcheck） 
前文已講過，Keepalived能夠經過在自身的Keepalived.conf文件裏配置LVS的節點IP和相關參數實現對LVS的直接管理；除此以外，當LVS集羣中的某一個甚至是幾個節點服務器同時發生故障沒法提供服務時，Keepalived服務會自動將失效的節點服務器從LVS的正常轉發隊列中清除出去，並將請求調度到別的正常節點服務器上，從而保證最終用戶的訪問不受影響；當故障的節點服務器被修復之後，Keepalived服務又會自動地把它們加入到正常轉發隊列中，對客戶提供服務。 
（3）做爲系統網絡服務的高可用功能（failover） 
Keepalived能夠實現任意兩臺主機之間，例如Master和Backup主機之間的故障轉移和自動切換，這個主機能夠是普通的不能停機的業務服務器，也能夠是LVS負載均衡，Nginx反向代理這樣的服務器。 
Keepalived高可用功能實現的簡單原理爲，兩臺主機同時安裝好Keepalived軟件並啓動服務，開始正常工做時，由角色爲Master的主機得到全部資源並對用戶提供服務，角色爲Backup的主機做爲Master主機的熱備；當角色爲Master的主機失效或出現故障時，角色爲Backup的主機將自動接管Master主機的全部工做，包括接管VIP資源及相應資源服務；而當角色爲Master的主機故障修復後，又會自動接管回它原來處理的工做，角色爲Backup的主機則同時釋放Master主機失效時它接管的工做，此時，兩臺主機將恢復到最初啓動時各自的原始角色及工做狀態。ios

3 Keepalived高可用故障切換轉移原理nginx

Keepalived高可用服務之間的故障切換轉移，是經過VRRP（Virtual Router Redundancy Protocol，虛擬路由器冗餘協議）來實現的。數據庫

一、VRRP協議：虛擬路由冗餘協議，VRRP，全稱Virtual Router Redundancy Protocol，中文名爲虛擬路由冗餘協議，VRRP的出現就是爲了解決靜態路由的單點故障問題，VRRP是經過一種競選機制來將路由的任務交給某臺VRRP路由器的。VRRP早期是用來解決交換機，路由器等設備單點故障的，下面是交換，路由的Master和Backup切換原理描述，一樣適用於Keepalived的工做原理。api

二、故障轉移瀏覽器

Keepalived高可用對，主k每秒發給備k發廣播包。若是備k接收不到廣播包就會認爲主k死了，立刻會搶走主k得vip。主k和備k是用一根網線直連得，叫心跳連接。band叫網卡綁定，防止腦裂。服務器

2、Keepalived高可用服務搭建準備

1 安裝Keepalived環境說明 
準備4臺物理服務器或4臺VM虛擬機，兩臺用來作Keepalived服務，兩臺作測試的Web節點 
兩個Keepalived服務得主機須要各自添加一塊網卡，而且要在同一網段。網絡

添加完網卡操做以下負載均衡

 
  1. [root@nginx~bak~]# cd /etc/sysconfig/network-scripts/
  2. [root@nginx~bak network-scripts]# cp ifcfg-eth0 ifcfg-eth1 #複製網卡配置文件爲eth1
  3. [root@nginx~bak network-scripts]# cat ifcfg-eth1
  4. DEVICE=eth1
  5. TYPE=Ethernet
  6. ONBOOT=yes
  7. NM_CONTROLLED=yes
  8. BOOTPROTO=dhcp

image_1cs3af83c1d4cis018lbld188mm.png-64.1kB

2 開始安裝Keepalived軟件,要在nginx~server和nginx~bak都安裝ide

 
  1. [root@nginx~server ~]# yum -y install keepalived
  2. [root@nginx~server ~]# rpm -qa keepalived
  3. keepalived-1.2.7-3.el6.x86_64

3 啓動Keepalived服務並檢查

 
  1. [root@nginx~server ~]# /etc/init.d/keepalived start
  2. [root@nginx~server ~]# ps -ef | grep keep | grep -v grep
  3. [root@nginx~server ~]# ip add | grep 192.168
  4. [root@nginx~server ~]# /etc/init.d/keepalived stop

image_1cs3b2iks1jvf1m3dj3o1poq1h5313.png-77.2kB

4 Keepalived配置文件說明 
Keepalived軟件的配置文件默認路徑及配置文件名爲：/etc/keepalived/keepalived.conf 
具有高可用功能的Keepalived.conf配置文件包含了兩個重要區塊 
(1) 全局定義（Global Definitions）部分

 
  1. 1 ! Configuration File for keepalived
  2. 2
  3. 3 global_defs {
  4. 4 notification_email {
  5. 5 acassen@firewall.loc
  6. 6 failover@firewall.loc
  7. 7 sysadmin@firewall.loc
  8. 8 }
  9. 9 notification_email_from Alexandre.Cassen@firewall.loc
  10. 10 smtp_server 192.168.200.1
  11. 11 smtp_connect_timeout 30
  12. 12 router_id LVS_DEVEL
  13. 13 }

第1行是註釋，！開頭和#號開發同樣，都是註釋。 
第2行是空行。 
第3~8行是定義服務故障報警的Email地址。做用是當服務發生切換或RS節點等有故障時，發報警郵件。這幾行是可選配置，notification_email指定在Keepalived發生事件時，須要發送的Email地址，能夠有多個，每行一個。 
第9行是指定發送郵件的發送人，即發件人地址，也是可選的配置。 
第10行smtp_server指定發送郵件的smtp服務器，若是本機開啓了sendmail或postfix，就可使用上面默認配置實現郵件發送，也是可選配置。 
第11行smtp_connect_timeout是鏈接smtp的超時時間，也是可選配置。

注意： 
第4~11行全部和郵件報警相關的參數都可以不配，在實際工做中會將監控的任務交給更加擅長監控報警的Nagios或Zabbix軟件。

第12行是Keepalived服務器的路由標識（router_id）.在一個局域網內，這個標識（router_id）應該是惟一的。 
大括號「{}」。用來分隔區塊，要成對出現。若是漏寫了半個大括號，Keepalived運行時，不會報錯，但也不會獲得預期的結果。另外，因爲區塊間存在多層嵌套關係，所以很容易遺漏區塊結尾處的大括號，要特別注意。

(2) VRRP實例定義區塊（VRRP instance（s））部分

 
  1. 15 vrrp_instance VI_1 {
  2. 16 state MASTER
  3. 17 interface eth0
  4. 18 virtual_router_id 51
  5. 19 priority 100
  6. 20 advert_int 1
  7. 21 authentication {
  8. 22 auth_type PASS
  9. 23 auth_pass 1111
  10. 24 }
  11. 25 virtual_ipaddress {
  12. 26 192.168.200.16
  13. 27 192.168.200.17
  14. 28 192.168.200.18
  15. 29 }
  16. 30 }

第15行表示定義一個vrrp_instance實例，名字是VI_1,每一個vrrp_instance實例能夠認爲是Keepalived服務的一個實例或者做爲一個業務服務，在Keepalived服務配置中，這樣的vrrp_instance實例能夠有多個。注意，存在於主節點中的vrrp_instance實例在備節點中也要存在，這樣才能實現故障切換接管。

第16行state MASTER表示當前實例VI_1的角色狀態，當前角色爲MASTER，這個狀態只能有MASTER和BACKUP兩種狀態，而且須要大寫這些字符。其中MASTER爲正式工做的狀態，BACKUP爲備用的狀態。當MASTER所在的服務器故障或失效時，BACKUP所在的服務器會接管故障的MASTER繼續提供服務。

第17行interface爲網絡通訊接口。爲對外提供服務的網絡接口，如eth0,eth1。當前主流的服務器都有2~4個網絡接口，在選擇服務接口時，要搞清楚了。

第18行virtual_router_id爲虛擬路由ID標識，這個標識最好是一個數字，而且要在一個keepalived.conf配置中是惟一的。可是MASTER和BACKUP配置中相同實例的virtual_router_id又必須是一致的，不然將出現腦裂問題。

第19行priority爲優先級，其後面的數值也是一個數字，數字越大，表示實例優先級越高。在同一個vrrp_instance實例裏，MASTER的優先級配置要高於BACKUP的。若MASTER的priority值爲150，那麼BACKUP的priority必須小於150，通常建議間隔50以上爲佳，例如：設置BACKUP的priority爲100或更小的數值。

第20行advert_int爲同步通知間隔。MASTER與BACKUP之間通訊檢查的時間間隔，單位爲秒，默認爲1.

第21~24行authentication爲權限認證配置。包含認證類型（auth_type）和認證密碼（auth_pass）。認證類型有PASS（Simple Passwd（suggested）），AH（IPSEC（not recommended））兩種，官方推薦使用的類型爲PASS。驗證密碼爲明文方式，最好長度不要超過8個字符，建議用4位數字，同一vrrp實例的MASTER與BACKUP使用相同的密碼才能正常通訊。

第25 ~ 29 行virtual_ipaddress爲虛擬IP地址。能夠配置多個IP地址，每一個地址佔一行，配置時最好明確指定子網掩碼以及虛擬IP綁定的網絡接口。不然，子網掩碼默認是32位，綁定的接口和前面的interface參數配置的一致。注意，這裏的虛擬IP就是在工做中須要和域名綁定的IP，即和配置的高可用服務監聽的IP要保持一致！

3、Keepalived高可用服務單實例實戰

1 配置Keepalived實現單實例單IP自動漂移接管 
（1）實戰配置Keepalived主服務器nginx~server

 
  1. #刪掉已有的全部默認配置，加入通過修改好的以下配置：
  2. 1 ! Configuration File for keepalived
  3. 2
  4. 3 global_defs {
  5. 4 notification_email {
  6. 5 3306684360@qq.com #郵箱隨便寫
  7. 6
  8. 7 }
  9. 8 notification_email_from Alexandre.Cassen@firewall.loc
  10. 9 smtp_server 127.0.0.1 #郵件服務器IP
  11. 10 smtp_connect_timeout 30
  12. 11 router_id lb01 #id爲lb1，不能和其餘Keepalived節點相同（全局惟一）
  13. 12 }
  14. 13
  15. 14 vrrp_instance VI_1 { #實例名字爲VI_1,相同實例的備節點名字要和這個相同
  16. 15 state MASTER #狀態爲MASTER，備節點狀態須要爲BACKUP
  17. 16 interface eth1 #通訊（心跳）接口爲eth1，此參數備節點設置和主節點相同
  18. 17 virtual_router_id 55 #實例ID爲55，要和備節點相同
  19. 18 priority 150 #優先級爲150，備節點的優先級必須比此數字低
  20. 19 advert_int 1 #通訊檢查間隔時間1秒
  21. 20 authentication {
  22. 21 auth_type PASS #PASS認證類型，此參數備節點設置和主節點相同
  23. 22 auth_pass 1111 #密碼1111，此參數備節點設置和主節點相同
  24. 23 }
  25. 24 virtual_ipaddress {
  26. 25 192.168.200.120/24 dev eht0 label eth0:1
  27. #虛擬IP，即VIP爲192.168.200.120,子網掩碼爲24位，綁定接口爲eth0，別名爲eth0：1，此參數備節點設置和主節點相同
  28. 26 }
  29. 27 }

配置完畢後，啓動Keepalived服務 
而後檢查配置結果，查看是否有虛擬IP 192.168.232.129 
image_1cs3drvp110qr1eq219juu0l1iq12a.png-8kB

(2) 實戰配置Keepalived備服務器nginx~bak

 
  1. #刪掉已有的默認配置，加入通過修改的以下配置（注意和lb01的不一樣）：
  2. ! Configuration File for keepalived
  4. global_defs {
  5. notification_email {
  6. 33063606@qq.com
  7. }
  8. notification_email_from Alexandre.Cassen@firewall.loc
  9. smtp_server 127.0.0.1
  10. smtp_connect_timeout 30
  11. router_id lb02 #此參數和nginx~server MASTER不一樣
  12. }
  14. vrrp_instance VI_1 { #和nginx~server 相同
  15. state BACKUP #此參數和nginx~server 不一樣
  16. interface eth1 #和nginx~server 相同
  17. virtual_router_id 55 #和nginx~server 相同
  18. priority 100 #此參數和nginx~server 不一樣
  19. advert_int 1
  20. authentication {
  21. auth_type PASS
  22. auth_pass 1111
  23. }
  24. virtual_ipaddress {
  25. 192.168.200.160/24 dev eth0 label eth0:1
  26. }
  27. }

image_1cs3fscfq18no1vqeum6sdueup37.png-17.5kB

出現上述無任何結果的現象，表示bak的Keepalived服務單實例配置成功。若是配置過濾後有192.168.200.160的IP，則表示Keepalived工做不正常，同一個IP地址同一時刻應該只能出現一臺服務器。 
若是查看BACKUP備節點VIP有以下信息，說明高可用裂腦了，裂腦是兩臺服務器爭搶同一資源致使的，例如：兩邊都配置了同一個VIP地址。 
出現上述兩臺服務器爭搶同一IP資源問題，通常要先考慮排查兩個地方： 
1）主備兩臺服務器對應的Keepalived.conf配置文件是否有錯誤？例如，是否同一實例的virtual_router_id配置不一致。

（3）進行高可用主備服務器切換實驗

上圖爲高可用主服務器正常運行時 
image_1cs3gjo2510rnm5t1sr0cgn4mn78.png-19.8kB

image_1cs3gl3rib631ekbv3nvn2sqq8l.png-14.8kB

主服務器宕機時 
image_1cs3ge8qe1jntq5b1t3b1api1h975u.png-31.2kB

image_1cs3gfmrmaqmb2u5lu1heonrv6b.png-24.2kB

 

說明： 這裏僅實現了VIP的自動漂移切換，所以，僅適合兩臺服務器提供的服務均保持開啓的應用場景，這也是工做中經常使用的高可用解決方案。

2 單實例主備模式Keepalived配置文件對比 
image_1cs3gq28h11itamgqim11p8pmv92.png-18.4kB

4、Keepalived高可用服務器的「裂腦」問題

1 什麼是裂腦 
因爲某些緣由，致使兩臺高可用服務器對在指定時間內，沒法檢測到對方的心跳消息，各自取得資源及服務的全部權，而此時的兩臺高可用服務器對都還活着並在正常運行，這樣就會致使同一個IP或服務在兩端同時存在而發生衝突，最嚴重的是兩臺主機佔用同一個VIP地址，當用戶寫入數據時可能會分別寫入到兩端，這可能會致使服務器兩端的數據不一致或形成數據丟失，這種狀況就被稱爲裂腦。

2 致使裂腦發生的緣由 
通常來講，裂腦的發生，有如下幾種緣由： 
（1）高可用服務器對之間心跳線鏈路發生故障，致使沒法正常通訊。 
（2）心跳線壞了（包括斷了,老化） 
（3）網卡及相關驅動壞了，IP配置及衝突問題（網卡直連）。 
（4）心跳線間鏈接的設備故障（網卡及交換機） 
（5）仲裁的機器出問題（採用仲裁的方案） 
（6）高可用服務器上開啓了iptables防火牆阻擋了心跳消息傳輸 
（7）高可用服務器上心跳網卡地址等信息配置不正確，致使發送心跳失敗。 
（8）其餘服務配置不當等緣由，如心跳方式不一樣，心跳廣播衝突，軟件BUG等

Keepalived配置裏同一VRRP實例若是virtual_router_id兩端參數配置不一致，也會致使裂腦問題發生。

3 解決裂腦的常見方案 
在實際生產環境中，咱們能夠從如下幾個方面來防止裂腦問題的發生：

同時使用串行電纜和以太網電纜鏈接，同時用兩條心跳線路，這樣一條線路壞了，另外一個仍是好的，依然能傳送心跳消息。 
當檢測到裂腦時強行關閉一個心跳節點（這個功能需特殊設備支持，如Stonith，fence）。至關於備節點接收不到心跳消息，經過單獨的線路發送關機命令關閉主節點的電源。 
作好對裂腦的監控報警（如郵件及手機短信等或值班），在問題發生時人爲第一時間介入仲裁，下降損失。例如，百度的監控報警短信就有上行和下行的區別。報警信息發送到管理員手機上，管理員能夠經過手機回覆對應數字或簡單的字符串操做返回給服務器，讓服務器根據指令自動處理相應故障，這樣解決故障的時間更短。 
固然，在實施高可用方案時，要根據業務實際需求肯定是否能容忍這樣的損失。對於通常的網站常規業務，這個損失是可容忍的。

4 解決Keepalived裂腦的常見方案 
做爲互聯網應用服務器的高可用，特別是前端Web負載均衡器的高可用，裂腦的問題對普通業務的影響是能夠忍受的，若是是數據庫或者存儲的業務，通常出現裂腦問題就很是嚴重了。所以，能夠經過增長冗餘心跳線路來避免裂腦問題的發生，同時增強對系統的監控，以便裂腦發生時人爲快速介入解決問題。

若是開啓防火牆，必定要讓心跳消息經過，通常經過容許IP段的形式解決。 
能夠拉一條以太網網線或者串口線做爲主被節點心跳線路的冗餘。 
開發檢測程序經過監控軟件（例如Nagios）檢測裂腦。 
下面是生產場景檢測裂腦故障的一些思路：

1)簡單判斷的思想：只要備節點出現VIP就報警，這個報警有兩種狀況，一是主機宕機了備機接管了；二是主機沒宕，裂腦了。無論屬於哪一個狀況，都進行報警，而後由人工查看判斷及解決。

2）比較嚴謹的判斷：備節點出現對應VIP，而且主節點及對應服務（若是能遠程鏈接主節點看是否有VIP就更好了）還活着，就說明發生裂腦了。

 

5、Keepalived雙實例雙主模式配置

1 Keepalived雙實例雙主模式配置實戰 
前面給出的是Keepalived單實例主備模式的高可用演示，Keepalived還支持多實例多業務雙向主備模式，即A業務在server上是主模式，在bak上是備模式，而B業務在server上是備模式，在bak上是主模式，下面就以雙實例爲例講解不一樣業務實現雙主的配置。

在server上配置Keepalived.conf，在單實例的基礎上增長一個vrrp_instance VI_2實例，步驟及內容以下：

 
  1. [root@nginx~server ~]# cat /etc/keepalived/keepalived.conf
  2. ! Configuration File for keepalived
  4. global_defs {
  5. notification_email {
  6. 3306684360@qq.com
  8. }
  9. notification_email_from Alexandre.Cassen@firewall.loc
  10. smtp_server 127.0.0.1
  11. smtp_connect_timeout 30
  12. router_id lb01
  13. }
  15. vrrp_instance VI_1 {
  16. state MASTER
  17. interface eth1
  18. virtual_router_id 55
  19. priority 150
  20. advert_int 1
  21. authentication {
  22. auth_type PASS
  23. auth_pass 1111
  24. }
  25. virtual_ipaddress {
  26. 192.168.200.160/24 dev eth0 label eth0:1
  27. }
  28. }
  29. vrrp_instance VI_2 {
  30. state BACKUP
  31. interface eth1
  32. virtual_router_id 56
  33. priority 100
  34. advert_int 1
  35. authentication {
  36. auth_type PASS
  37. auth_pass 1111
  38. }
  39. virtual_ipaddress {
  40. 192.168.200.170/24 dev eth0 label eth0:2
  41. }
  42. }
  44. 以vrrp_instance VI_1在server 服務器上的角色爲主，vrrp_instance VI_2在server 服務器上的角色爲備。

在bak上配置Keepalived.conf，在單實例的基礎上增長一個vrrp_instance VI_2實例，步驟及內容以下：

 
  1. [root@nginx~bak ~]# cat /etc/keepalived/keepalived.conf
  2. ! Configuration File for keepalived
  4. global_defs {
  5. notification_email {
  6. 33063606@qq.com
  7. }
  8. notification_email_from Alexandre.Cassen@firewall.loc
  9. smtp_server 127.0.0.1
  10. smtp_connect_timeout 30
  11. router_id lb02
  12. }
  14. vrrp_instance VI_1 {
  15. state BACKUP
  16. interface eth1
  17. virtual_router_id 55
  18. priority 100
  19. advert_int 1
  20. authentication {
  21. auth_type PASS
  22. auth_pass 1111
  23. }
  24. virtual_ipaddress {
  25. 192.168.200.160/24 dev eth0 label eth0:1
  26. }
  27. }
  28. vrrp_instance VI_2 {
  29. state MASTER
  30. interface eth1
  31. virtual_router_id 56
  32. priority 150
  33. advert_int 1
  34. authentication {
  35. auth_type PASS
  36. auth_pass 1111
  37. }
  38. virtual_ipaddress {
  39. 192.168.200.170/24 dev eth0 label eth0:2
  40. }
  41. }

vrrp_instance VI_1在bak 服務器上的角色爲備，vrrp_instance VI_2在bak 
服務器上的角色爲主。

image_1cs3jei14a9230qmjs4oapham.png-139.7kB

測試： 
一、 
image_1cs3huvlt15an3qf17bl1s791aus9f.png-20.8kB 
二、 
image_1cs3ilh691vvt14883ib1jh1170r9s.png-41.5kB
三、 
image_1cs3jqe6dcnibh96d2n2finuc3.png-36.1kB

特別提示： 若是測試結果不符，請查看是否沒有關閉iptables 
到此爲止，咱們發現sever，bak主備節點已經實現了初始配置的VIP服務狀態，當任意一端宕機，VIP能夠實現互相切換接管。在實際工做中，能夠把www.mendermi.com解析到192.168.200.140提供服務，把bbs.yunjisuan.com解析到192.168.200.139提供服務，固然了，server，bak也要配置相應服務，例如：Nginx反向代理服務等。

 

6、Nginx負載均衡配合Keepalived服務案例實戰

1 在server和bak上配置Nginx負載均衡

image_1cs3l22pg5as10qg165ekn37vpcg.png-46.8kB

image_1cs3l48ku14q31g5a1cvt1edm216dd.png-47.6kB

二、用戶訪問準備

（1）在客戶端hosts文件裏把www.mendermi.com域名解析到VIP 192.168.200.160上，正式場景需經過DNS解析。bbs.mendermi.com域名解析到VIP 192.168.200.170上

（2）兩臺服務器配好Nginx負載均衡服務，而且確保後面代理的Web節點能夠測試訪問。 
image_1cs3lddr7sr2ro6u2ife65ksdq.png-15.7kB

image_1cs3ldrmce7j1u80l0n1tmginge7.png-16kB

(3）下面模擬實際的訪問過程 
經過客戶端瀏覽器輸入www.mendermi.com測試訪問，正常應該顯示下圖。 
image_1cs3lfgee5m11m65jqm1lkm155lek.png-11.1kB

image_1cs3lft0pik31q6m1qn01clrtb5f1.png-11.5kB

此時中止server服務器或停掉Keepalived服務，觀察業務是否正常： 
image_1cs3ljhc215itnn51l1i1ssmbq2fe.png-24.5kB

觀察bak備節點是否接管了VIP 192.168.200.160 
image_1cs3lmjik671msm198o1f5o1mn8fr.png-25.2kB

再次經過客戶端瀏覽器輸入www.mendermi.com測試訪問，正常應該出現關閉server的keepalives服務前的結果，顯示下圖。 
image_1cs3lo10p7m2nop1epj1gk137eg8.png-11.2kB

image_1cs3logojeqs1ce21h0t1aea1b9egl.png-11.5kB

（4）開啓lb01的Keepalived服務

image_1cs3m8qd913ur1e411ure15jj18o3h2.png-95.3kB

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程