2. 程式人生 > >Keepalive 之 高可用實現

Keepalive 之 高可用實現

阿新 • • 發佈：2017-11-02
fwmark lvs nginx keepalive

1 概述

本文將介紹三個Keepalive高可用的實現案例，分別是keepalive實現LVS高可用，keepalive通過fwmark實現LVS高可用，keepalive實現Nginx高可用。

2 實驗準備

.(1) 各節點時間必須同步，這個操作很關鍵。工具有ntp 和chrony（CentOS7上開始啟用）

.(2) 確保iptables及selinux不會成為阻礙。7上要停止firewalld服務和iptables

.(3) 各節點之間可通過主機名互相通信（對KA並非必須），建議使用/etc/hosts文件實現

172.18.50.63和73 上配置

echo"172.18.50.63 node1 ">>/etc/hosts

echo"172.18.50.73 node2">>/etc/hosts

.(4) 各節點之間的root用戶可以基於密鑰認證的ssh服務完成互相通信（對KA並非必須，但是建議配置）

兩臺都要設置

172.18.50.63上配置

ssh-keygen

ssh-copy-id -i /root/.ssh/id_rsa.pub 172.18.50.73

172.18.50.73上配置

ssh-keygen

ssh-copy-id -i /root/.ssh/id_rsa.pub 172.18.50.63

(5)多播地址

建議更改默認的多播地址，防止沖突，可以在配置文件裏的全局加入選項vrrp_mcast_group4224.100.50.100

。將組播地址調整為224.100.50.100。

網卡需要支持多播模式，默認網卡都開啟多播功能，可以使用如下的命令關閉多播地址（不能關閉該功能，僅當學習）：

ip link set dev eth1 multicast off.

(6)測試

通過抓包查看

tcpdump -i eth1 -nn host 組播ip,如下

tcpdump -i eth1 -nn host 224.50.50.50

註意，如果對應的主服務器的keepalived服務被停了，就會發一條優先級為0的狀態。查看vip地址用ip a命令查看對應主機是否將VIP加入到網卡裏

3 配置介紹

.虛擬服務器：

.配置參數：

有兩個配置的方法

virtual_server IP port

定義vip和端口，實現對該vip的統一調度

virtual_server fwmark int：指在keepalive的機器上的防火墻mangle表打標簽。同一標簽的主機實現同一的調度。如對外同一服務有兩個ip，vip1 和vip2,後端有4臺RS，vip1和vip2在mangle表上打同一標簽，後臺的4臺RS都配置這兩個vip，那麽keepalive服務器就可以實現訪問這兩個vip時，實現對這四臺RS的統一調度

virtual_server  IP port | virtual_server  fwmark int
{
    ...
    real_server{
    ...
    }
    ...
}

常用參數

.delay_loop  <INT>：服務輪詢的時間間隔
.lb_algo  rr|wrr|lc|wlc|lblc|sh|dh：定義調度方法
.lb_kind  NAT|DR|TUN：集群的類型
.persistence_timeout  <INT>：持久連接時長
.protocol TCP：服務協議，僅支持TCP
.sorry_server  <IPADDR>   <PORT>：所有RS故障時，備用服務器地址
#以下配置，有幾臺RS就要重復配置幾遍
.real_server<IPADDR><PORT>
{
weight   <INT> RS權重
notify_up  <STRING>|<QUOTED-STRING> RS上線通知腳本
notify_down  <STRING>|<QUOTED-STRING> RS下線通知腳本
HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK   { ...}：定義當前主機的健康狀態檢測方法
}

KeepAlived配置檢測

.HTTP_GET|SSL_GET：應用層檢測
HTTP_GET|SSL_GET {
url{
path  <URL_PATH>：定義要監控的URL
status_code  <INT>：判斷上述檢測機制為健康狀態的響應碼
digest  <STRING>：判斷為健康狀態的響應的內容的校驗碼
}
connect_timeout  <INTEGER>：連接請求的超時時長
nb_get_retry  <INT>：重試次數
delay_before_retry  <INT>：重試之前的延遲時長
connect_ip   <IPADDRESS>：向當前RS哪個IP地址發起健康狀態檢測請求，分流，定義用來監控的網卡和提供服務的網卡不一樣
connect_port  <PORT>：向當前RS的哪個PORT發起健康狀態檢測請求
bindto   <IP ADDRESS>：發出健康狀態檢測請求時使用的源地址
bind_port  <PORT>：發出健康狀態檢測請求時使用的源端口
}
 
.TCP_CHECK {
connect_ip <IP ADDRESS>：向當前RS的哪個IP地址發起健康狀態檢測請求
connect_port <PORT>：向當前RS的哪個PORT發起健康狀態檢測請求
bindto  <IP ADDRESS>：發出健康狀態檢測請求時使用的源地址
bind_port <PORT>：發出健康狀態檢測請求時使用的源端口
connect_timeout <INTEGER>：連接請求的超時時長
}

4 案例實現

所有實驗會用到通知腳本和RS配置腳本，所以，將這兩個腳本單獨放置

4.1示例通知腳本

這裏例子是發郵件的腳本，實際情況當角色發生變化的時候，需要服務器執行什麽操作可以直接寫入腳本裏，而不僅僅是發郵件通知，從而實現其他應用的高可用。

#!/bin/bash
#
contact=‘root@localhost‘
notify() {
mailsubject="$(hostname) to be $1, vip
floating"
mailbody="$(date +‘%F %T‘): vrrp transition,
$(hostname) changed to be $1"
echo "$mailbody" | mail -s
"$mailsubject" $contact
}
case  $1  in
master)
notify master
;;
backup)
notify backup
;;
fault)
notify fault
;;
*)
echo "Usage: $(basename $0)
{master|backup|fault}"
exit 1
;;
esac

.腳本的調用方法：

直接寫入配置文件VRRPD配置段裏

notify_master  "/etc/keepalived/notify.sh master"
notify_backup  "/etc/keepalived/notify.sh backup"
notify_fault   "/etc/keepalived/notify.sh fault"

重啟服務，用mail查看

4.2 RS配置

#!/bin/bash
#
#******************************************************************************
#Author:                 Sunny
#Date:                 2017-10-24
#FileName:                  lvs_dr_rs.sh
#version:                 1.0
#Your change info:      
#Description:                   For auto set RS_dr
#DOC URL:               http://ghbsunny.blog.51cto.com/7759574/1975813 
#Copyright(C):                2017  All rights reserved
#*****************************************************************************
vip=172.18.50.80
mask=‘255.255.255.255‘
dev=lo:1
rpm -q httpd &> /dev/null || yum -y install httpd &>/dev/null
service httpd start &> /dev/null && echo "The httpd Server is Ready!"
echo "<h1>`hostname`</h1>" > /var/www/html/index.html

case $1 in
start)
    echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
    echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
    echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
    echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
    ifconfig $dev $vip netmask $mask broadcast $vip up
    echo "The RS Server is Ready!"
    ;;  
stop)
    ifconfig $dev down
    echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
    echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore
    echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
    echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce
    echo "The RS Server is Canceled!"
    ;;  
*) 
    echo "Usage: $(basename $0) start|stop"
    exit 1
    ;;  
esac


4.3 keepalive實現LVS高可用

實現效果是當有請求過來時，根據輪詢規則調度到後端RS,同時實現了對RS的健康性檢查，同時實現VS的高可用

拓撲圖如下

技術分享

4.3.1 HA1 配置如下

! Configuration File for keepalived

global_defs {
   notification_email {
   		root@localhost
   }
   notification_email_from node1@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id node1
   vrrp_mcast_group4 224.50.50.50
}

vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass sunny
    }
    virtual_ipaddress {
		172.18.50.80
    }
	notify_master "/etc/keepalived/vip1_notify.sh master"
    notify_backup "/etc/keepalived/vip1_notify.sh backup"
    notify_fault  "/etc/keepalived/vip1_notify.sh fault"
 virtual_server 172.18.50.80 80 {
 delay_loop 3
 lb_algo wrr 
 lb_kind DR
 protocol TCP 
 sorry_server 127.0.0.1 80
    real_server 172.18.50.65 80 {
    weight 2
    HTTP_GET {
        url {
        path /
        status_code 200 
        }   
    connect_timeout 1
    nb_get_retry 2
    delay_before_retry 1
    }   
    }   
    real_server 172.18.50.75 80 {
    weight 1
    HTTP_GET {
        url {
        path /
        status_code 200 
        }   
    connet_timeout 1
    nb_get_retry 2
    delay_before_retry 1
        }   
    }   
 }
}

HA2只需調整優先級，stats 為BACKUP，網卡等相關信息，其他不變，RS配置參考3.2，註意VIP使用32位，防止路由問題，導致調度不通，然後測試

4.4 keepalive通過fwmark實現LVS高可用

基於fwmark雙主模式的lvs集群，基於fwmark，實現雙主高可用的前提下，根據防火墻prerouting鏈上的mark會將所有的請求均勻調度。


技術分享

4.4.1 打標簽

在兩臺63和73上keepalive機器上防火墻的mangle表打標簽，命令如下

iptables -t mangle -A PREROUTING -d172.18.50.80,172.18.50.90 -p tcp --dport 80 -j MARK --set-mark 6

4.4.2 HA1 上配置

! Configuration File for keepalived

global_defs {
   notification_email {
   		root@localhost
   }
   notification_email_from node1@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id node1
   vrrp_mcast_group4 224.50.50.50
}

vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass sunny
    }
    virtual_ipaddress {
		172.18.50.80
    }
	notify_master "/etc/keepalived/vip1_notify.sh master"
    notify_backup "/etc/keepalived/vip1_notify.sh backup"
    notify_fault  "/etc/keepalived/vip1_notify.sh fault"
}

 virtual_server fwmark 6 {
 delay_loop 3
 lb_algo wrr 
 lb_kind DR
 protocol TCP 
 sorry_server 127.0.0.1 80
    real_server 172.18.50.65 80 {
    weight 1
    HTTP_GET {
        url {
        path /
        status_code 200 
        }   
    connect_timeout 1
    nb_get_retry 2
    delay_before_retry 1
    }   
    }   
    real_server 172.18.50.75 80 {
    weight 1
    HTTP_GET {
        url {
        path /
        status_code 200 
        }   
    connet_timeout 1
    nb_get_retry 2
    delay_before_retry 1
        }   
	}  
}

4.4.3 配置RS1和RS2，參考3.2，然後進行測試

4.5 keepalive實現Nginx高可用

.keepalived調用外部的輔助腳本進行資源監控，並根據監控的結果狀態能實現優先動態調整

.vrrp_script:自定義資源監控腳本，vrrp實例根據腳本返回值，公共定義，可被多個實例調用，定義在vrrp實例之外

.track_script:調用vrrp_script定義的腳本去監控資源，定義在實例之內，調用事先定義的vrrp_script

.分兩步：(1)先定義一個腳本；(2) 調用此腳本。

vrrp_script  <SCRIPT_NAME> {
script " " #這裏寫腳本的真實路徑，也可以是bash命令
interval INT  #多久執行一次腳本
weight  -INT #當主服務異常，把之前定義的vrrp權重減掉多少，減少得比backup的值還低，這樣就可以實現對別得應用的高可用性的支持
}
track_script {
#以下是調用腳本，這裏相當於是虛擬路由器的代碼段
SCRIPT_NAME_1
SCRIPT_NAME_2
}

示例：高可用nginx服務

技術分享

兩臺nginx服務器上分別安裝keepalive,通過腳本檢查keepalive 和 nginx是否存在，實現高可用。

一般只有一臺keepalive的級別高，所以該機器的nginx起作用，負責調度，當nginx異常，權重減去20後，備用的keepalive起作用，備用機器刪的nginx接管工作。後端的RS是定義在nginx的http配置段裏

chk_down 的函數作用是檢查/etc/keepalived/down文件存在時，就返回1，就將keepalive權重減去20。vip將配置到另一臺主機，使得備用主機生效。當/etc/keepalived/down刪掉後，該主機的優先級就會自動加上20.重新搶占vip。

chk_nginx 的函數作用是檢查nginx是否正常運行，當nginx異常時，就將keepalive優先級減去20。vip將配置到另一臺主機，使得另一臺的keepalive生效當nginx重新工作後，該主機的優先級就會自動加上20.重新搶占vip。

4.5.1 HA1配置如下

! Configuration File for keepalived

global_defs {
   notification_email {
   		root@localhost
   }
   notification_email_from node1@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id node1
   vrrp_mcast_group4 224.50.50.50
}

vrrp_script  chk_down {
script "[[ -f   /etc/keepalived/down ]] && exit 1 || exit 0"
interval  1
weight  -20 
 }

vrrp_script  chk_nginx {
script "killall -0 nginx && exit 0 || exit 1"
interval 1
weight  -20
fall 2 
rise 1 
}


vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass sunny
    }
    virtual_ipaddress {
		172.18.50.80
    }
	notify_master "/etc/keepalived/vip1_notify.sh master"
    notify_backup "/etc/keepalived/vip1_notify.sh backup"
    notify_fault  "/etc/keepalived/vip1_notify.sh fault"

	track_script {
	 chk_down
	 chk_nginx
	   }


}

4.5.2 nginx 配置如下

    http{
        ......
          upstream websrvs {
        server 172.18.50.75:80 weight=1;
        server 172.18.50.65:80 weight=2;
        server 127.0.0.1:8000 backup;
            }   
        ......
    }   

    server {
        .....
            location / { 
        proxy_pass http://websrvs;
            }   
        ......
    }

4.5.3 測試

創建/etc/keeplived/down文件以及關閉keepalive查看實驗

本文出自 “陽光運維” 博客，請務必保留此出處http://ghbsunny.blog.51cto.com/7759574/1978259

Keepalive 之 高可用實現

相關推薦

Keepalive 之 高可用實現

fwmark lvs nginx keepalive1 概述本文將介紹三個Keepalive高可用的實現案例，分別是keepalive實現LVS高可用，keepalive通過fwmark實現LVS高可用，keepalive實現Nginx高可用。2 實驗準備.(1) 各節點時間必須同步，這個操作很關鍵。

MySQL的高可用實現：MySQL系列之十四

一致性 ilo ply purge shutdown monitor 半同步 eve 延遲 MySQL的高可以有三種實現方式：多主模式（Multi Master MySQL），MHA（Master High Availability）和 Galera Cluster：wr

MySQL之高可用架構—MHA

mysql mha MySQL高可用目前有heartbeat+drbd、MHA、MySQL復制等幾種較成熟的方案，heartbeat+drbd的方案可擴展性較差，而且讀寫都由主服務器負責，從庫並不提供讀功能，適合於數據增長量不大、一致性要求很高的環境，如銀行、金融業等。今天重點講下MHA的高可用架構。

LVS 之 高可用性

ldirectord 自動化腳本1 概述 在lvs的集群設計中，存在兩個地方不可用的問題，Director不可用 和RS不可用A)Director不可用Director不可用整個系統將不可用；SPoF Single Point of Failure,單點故障導致解決方案：通過keepalived he

LVS高可用實現

LVS-DR問題:LVS由於沒有健康行檢查功能,當後端RS出現問題的時候還是會調度到損壞的RS服務器上 解決:1 編寫腳本(編寫一個for循環腳本,VS服務器每過1s使用curl命令訪問一下後端的RS服務器,查看$?是否為0,不為0就使用ipvsadm -d刪除即可) 2 ldirectord

大數據之高可用Mongodb集群部署

大數據 在這裏相信有許多想要學習大數據的同學，大家可以關註小編頭條號和轉發，關註私信【學習> 】即可免費領取一整套系統的大數據學習教程 另外，大數據初學者有什麽不懂的可以關註私信【學習】和轉發——我剛整理了一份大數據 2018最新的0基礎入門和進階教程，無私分享 大數據之高可用Mongodb集群

LVS/DR + keepalived負載均衡高可用實現

ha lvs keepalive 一、keepalived簡介keepalived是分布式部署解決系統高可用的軟件，結合lvs(LinuxVirtual Server)使用，解決單機宕機的問題。keepalived是一個基於VRRP協議來實現IPVS的高可用的解決方案。對於LVS負載均衡來說，如果

Mysql數據庫學習之高可用架構Atlas簡析

mysql數據庫 北京mysql mysql周末 數據庫管理員 　　Atlas是一個基於MySQL協議的數據中間層項目，在MySQL-Proxy 0.8.2版本基礎上修改了大量bug，添加了很多功能特性。目前該項目很多MySQL業務已經接入了Atlas平臺，每天承載的讀寫請求數達幾十億條。　

深入解讀HBase2.0新功能之高可用讀Region Replica

數據庫摘要： 基於時間線一致的高可用讀（Timeline-consistent High Available Reads），又稱Region replica,為HBase帶來了高可用讀的能力。本文主要介紹region replica這個功能設計的背景，技術細節和使用方法，同時會仔細分析這個功能的優缺點並給出使

MySQL數據庫之高可用MHA簡介 MySQL學習

手動 style mysql故障 font 簡介 ica bat replicat 自動 　　MHA目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton開發，是一套優秀的作為MySQL高可用性環境下故障切換和主從提升的高可用軟件。在

haproxy高可用實現 和 動靜資源的調度分離

keepal 進行 memcached 管理 gin stats 均衡 17. 虛擬ip 一、項目作業： (1) 動靜分離部署wordpress，動靜都要能實現負載均衡，要註意會話的問題； (2) 配置memcached服

MySQL入門篇（五）之高可用架構MHA

數據節點 ability ast 圖片 故障轉移 5.5 架構 日本 丟失 一、MHA原理 1、簡介： MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton（現就職於

Mysql 之 高可用負載均衡

可用 type color image oss com -o watermark size Mysql 之 高可用負載均衡 Mysql 之 高可用負載均衡

Hadoop安裝之高可用搭建

通過前面兩篇文章的搭建，可以發現搭建的NameNode只有一臺，沒有進行備份機，如果NameNode宕機了，那整個叢集也就廢了，所以我們需要在另外的機器上再搭建一個NameNode節點，且使用JournalNode來保證兩臺NameNode中的元資料保持一致，並且還需要通過zookeeper的zkF

架構應用之高可用、高複用

架構應用之高可用、高複用 。   一、儲存高可用 儲存的高可用，主要是通過資料冗餘的方式來實現高可用，複雜性主要是在如何保持資料一致性，複製延遲和網路中斷都會帶來資料不一致。主要考慮的就是，資料如何複製，如何應對複製延遲，如何應對複製中斷，各個節點的職責是什麼。

微服務實戰之高可用性

高可用性指你提供的服務要始終可用, 不管天災(停電, 斷網, 磁碟空間滿, 伺服器硬體損壞等), 人禍(軟體bug, 黑客破壞, 誤操作等), 甚至地震, 洪水抑或戰爭. 高可性性的指標就是可用時間與總時間之比 availability = uptime/(uptime + down

Redis之高可用方案

Redis以其高效的訪問速度著稱。但由於官方還未釋出redis-cluster，而redis的replica又有諸多不便：比如一組master-slave的機器，如果之間有連結瞬段，或者對slave重新執行slaveo

高可用架構之高可用的應用和服務

高可用的網站架構需要網站應用每個層面的支援，本文著重介紹應用層和服務層的高可用的解決方案。 1、高可用的應用 應用層主要處理網站應用的業務邏輯，因此有時也被稱作業務邏輯層，應用的一個顯著特點是應用的無狀態性。 所謂無狀態的應用是指應用伺服器不儲存業務的上下文資訊，而僅根據

Hiveserver2高可用實現

在生產環境中使用Hive，強烈建議使用HiveServer2來提供服務，好處有: 在應用端不用部署Hadoop和Hive客戶端； 相比hive-cli方式，HiveServer2不用直接將HDFS和Metastore暴漏給使用者； 有安全認證機制，並且支援自定義許可權校驗； 有HA機制，解

深入解讀 HBase2.0 新功能之高可用讀 Region Replica

1.前言 基於時間線一致的高可用讀(Timeline-consistent High Available Reads)，又稱 Region replica。其實早在 HBase-1.2 版本的時候，這個功能就已經開發完畢了， 但是還是不太穩定，離生產可用級別還有一段距離，後來社群又陸陸續續修復了 一些 bu