前言

本文要說的是基于 keepalived 實現兩臺服務器之間的主備切換，從而實現 Java 服務的高可用。keepalived 的原理不多做介紹，自行搜索了解，keepalived 的安裝部署請參考 keepalived 的安裝及使用 。

個人建議

不要沉迷于 死扣 和 理解 原理，網上關于原理的文章大同小異，關鍵詞就是 虛擬ip，了解個大概，動手實踐下，結合 keepalived 的配置文件會更好。

項目描述

我所做的項目是不是一個 web 程序，主要功能是定時從文件服務器下載文件，然后做一些處理，放到本地。

需求

當一臺服務器部署的系統出現故障時，能夠有備用機器繼續提供服務，盡量避免人工介入去恢復系統。注意跟負載均衡的區別！初步方案只提供一臺備用機。

方案

1. 實現原理

keepalived 的配置文件中有 權重 和 STATE 兩個配置項，兩臺機器上的 keepalived 通過 虛擬IP 綁定之后，它們之間就可以通過上述的配置項來進行 ”選舉“ ，區分 MASTER 和 BACKUP 。

然后配合 keepalived 中另外的兩個功能，檢測腳本 和 通知腳本 實現我們的主備切換的需求。

到底如何決定 MASTER 和 BACKUP ？

STATE 的值可以是 MASTER 和 BACKUP，當 兩臺機器配置的 STATE 的值相同，并且權重相同時，誰先啟動誰是 MASTER，當兩臺機器的配置的 權重 相同時，state 為 MASTER 的那臺機器最終會成為 MASTER(哪怕這臺機器啟動的時間比另一臺晚)

檢測腳本的作用

對我們的使用場景來說，檢測腳本的作用有兩個，一是檢測我們的 java 進程是否存在，二是對 keepalived 的權重進行加減。比如： 檢測到我們的 java 進程關閉了，我們就可以降低這臺機器的權重。

權重改變是永久生效的嗎？

否， 權重的增加或者降低只對當前一輪的檢測有效！下次檢測開始還會恢復到配置的默認值。

通知腳本的作用

通知腳本有兩種，分別根據 keepalived 的狀態去觸發。對我們的使用場景來說，這兩種分別是： **一個是當這臺機器是 MASTER 時需要觸發的腳本，二是當這臺機器是 BACKUP 的時候需要觸發的腳本。**比如： 當我們的機器變成 MASTER 時，去啟動我們的 java 進程。

2. 具體配置

keepalived 的配置文件

! Configuration File for keepalived

# 全局配置

global_defs {

router_id LVS_MS

vrrp_skip_check_adv_addr

vrrp_garp_interval 0

vrrp_gna_interval 0

}

# 配置檢測腳本，腳本名稱隨意

vrrp_script chk {

script "/etc/keepalived/chk.sh" # 檢測腳本的位置

interval 3 # 每隔 3 秒執行一次

weight -20 # 權重 -20 ，根據檢測腳本的返回值去判斷是否要減掉

}

# vrrp 實例

vrrp_instance VI_1 {

state BACKUP # 主備配置一樣，并且權重也一樣，這樣誰先啟動誰就是 MASTER

interface eth0

virtual_router_id 90

priority 100 # 默認權重

advert_int 1

authentication {

auth_type PASS

auth_pass keepalived_ms

}

virtual_ipaddress {

172.16.10.90 # 虛擬 ip

}

# 引用檢測腳本，因為可以配置多個 vrrp 實例，每個實例都可以使用同一個檢測腳本

track_script {

chk

}

# 配置通知腳本的路徑，腳本名稱隨意

# 1. 當 keepalived 的狀態為 MASTER 時，會觸發這個通知腳本

notify_master "/etc/keepalived/notify.sh master"

# 2. 與 1 相反

notify_backup "/etc/keepalived/notify.sh backup"

}

檢測腳本

#!/bin/bash

# 查找java服務進程個數

count=`ps aux | grep -v grep | grep 進程名稱 | wc -l`

# master.flag 就是一個標記文件，如果文件存在，表示為 master

# 如果 MASTER 上的服務down 掉，降低權重

# 如果 MASTER 上的服務沒有問題，權重不變

# 如果是BACKUP ，權重保持不變

if [ -f master.flag ] && [ $count -eq 0 ]; then

exit 1 # 結合 keepalived.conf 配置文件，這里返回 1 表示當前機器權重 -20

else

exit 0 # 返回 0 ，什么也不做

fi

檢測腳本什么時候執行？

檢測腳本時定時執行的，時間可以配置，而且主備兩臺機器都會同時執行。

通知腳本

#!/bin/bash

# 接收參數， master 或者 backup 或者 ""

function=$1

# 如果觸發的是 master 的通知腳本

if [ "x"$function = "xmaster" ] ; then

# 1. 新建標記文件，標志本機為 MASTER

touch master.flag

# 2. 啟動 java 進程

# TODO

# 3. 啟動文件同步服務

# TODO 這里是因為我的項目需要，所以要開啟這樣一個服務

else

# 1. 刪除 MASTER 標記，標記為 BACKUP

rm -f master.flag

# 2. 關閉 java 進程

# TODO 為了保險一點，再關閉一次

# 3. 關閉文件同步服務

# TODO

fi

通知腳本什么時候執行?

只有當狀態發生切換時(包括 keepalived 啟動時)，才會觸發對應的通知腳本。

執行流程

首先是準備兩臺機器比如 Server A 和 Server B，分別部署我們的 java 應用 和 keepalived，甚至其他可能用到的服務，比如我們項目中用的文件同步。

分別啟動兩臺機器的 keepalived 進程，順序無所謂，配置文件都一樣，誰先啟動誰就是 master。

比如 Server A 是 MASTER，keepalived 就會去觸發我們的通知腳本(notify_master)，通知腳本就會創建一個文件標記這臺機器是 master，同時啟動我們的 java 進程。Server B 的 keepalived 啟動后，觸發 notify_slave, 結合腳本所做的事情，我們發現，第一次觸發并不會造成什么影響，甚至后續我們可以優化一下，減少這些無用功。

當我們關閉 Server A 的 java進程，檢測腳本檢測到 java 進程關閉了，并且當前主機是 MASTER (因為檢測到 master.flag 文件存在)，檢測腳本就會返回 1，致使 Server A 的權重降低 20，也就是比 Server B 低20，此時會在此進行 “選舉”，Server A 就變成了 backup，同時去觸發notify_slave腳本，Server B 就變成了 master， 同時觸發 notify_master腳本。

根據兩個腳本做的事情，我們最終發現，兩臺機器不僅發生了身份切換，并且做的事情也對換了一下。

幾個問題

keepalived 的日志存放位置 ： /var/log/messages

如果發現兩邊都能檢測到虛擬ip，請檢查下 防火墻是否沒有關閉！

檢測腳本和通知腳本的執行順序： 同時執行！ 這也是我為什么加了 master.flag 的原因。 請仔細體會！

總結

上述僅僅是一個 demo 方案，并未經過生產環境的考驗，需要打磨的地方很多。另外就是網上做此類方案的案例很少，可能是應用不到吧，其他大多方案都是，kill 掉 keepalived 從而完成主備切換。寫這篇文章的主要原因是自己在做的過程中，有很多疑惑，網上沒直接給出答案，其實正常操作的話不會有我這些疑惑，我是因為腳本寫錯了，在我堅定腳本沒問題的時候，去懷疑一些問題，比如權重改變后就永久生效了，通知腳本是根據你的狀態一直在執行的！

?---有點兒` 菜！

最后歡迎大家指出其中的問題，或者做一些補充！！ 謝謝

總結

以上是生活随笔為你收集整理的java 主备切换_keepalived 实现 Java 服务的高可用（主备切换）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。