Linux集群架構

高可用集群通常為2臺伺服器（功能和角色是一樣的），一台在工作，另一台作為冗餘。當提供服務的機器宕機，冗餘將接替繼續提供服務，這樣就可以提供系統可用的效率。

高可用集群的衡量標準

要保證集群服務100%時間永遠完全可用，幾乎可以說是一件不可能完成的任務。比如，**在這幾年雙十一剛開始的時候，一下子進來買東西的人很多，訪問量大，都出現一些問題，如下單後卻支付不了。所以說只能保證服務盡可能的可用，當然有些場景相信還是可能做到100%可用的。通常用平均無故障時間(mttf)來度量系統的可靠性,用平均故障維修時間（mttr）來度量系統的可維護性。於是可用性被定義為：ha=mttf/(mttf+mttr)*100%。

具體ha衡量標準:

描述

通俗叫法

可用性級別

年度停機時間

基本可用性

2個999%

87.6小時

較高可用性

3個999.9%

8.8小時

具有故障自動恢復能力的可用性

4個999.99%

53分鐘

極高可用性

5個999.999%

5分鐘

負載均衡集群

需要有一台伺服器作為分發器，它負責把使用者的請求分發給後端的伺服器處理，在這個集群裡，除了分發器外，就是給使用者提供服務的伺服器了，這些伺服器數量至少是2臺。

實現負載均衡的開源軟體有lvs keepalived haproxy nginx ,商業使用的有f5 和netscaler等負載均衡器。優勢在於更高的應答量和良好的穩定性。

使用開源軟體來搭建的負載均衡，其穩定性依賴伺服器的穩定性

global_defs // notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id lvs_devel }vrrp_script chk_nginx vrrp_instance vi_1 virtual_ipaddress track_script

}

#!/bin/bash #時間變數，用於記錄日誌 d=`date --date today +%y%m%d_%h:%m:%s` //表示時間 #計算nginx程序數量 n=`ps -c nginx --no-heading|wc -l` //計算nginx的程序數 #如果程序為0，則啟動nginx，並且再次檢測nginx程序數量， #如果還為0，說明nginx無法啟動，此時需要關閉keepalived if [ $n -eq"0" ]; then /etc/init.d/nginx start n2=`ps -c nginx --no-heading|wc -l` if [ $n2 -eq"0" ]; then echo "$d nginx down,keepalived will stop" >> /var/log/check_ng.log systemctl stop keepalived //nginx服務沒有啟動時，停止keepalived,給backup使用。

fifi

chmod 755 /usr/local/sbin/check_ng.sh [root@chunt ~]# systemctl start keepalived [root@chunt ~]# ps aux |grep keepalived root 1582 0.00.1 120740 1408 ? ss 00:38 0:00 /usr/sbin/keepalived -d root 1583 0.00.3 127476 3276 ? s 00:38 0:00 /usr/sbin/keepalived -d root 1584 0.20.3 131780 3116 ? s 00:38 0:00 /usr/sbin/keepalived -d root 1640 0.00.0 112676 980 pts/1 s+ 00:39 0:00 grep --color=auto keepalived

[root@chunt ~]#

[root@spring ~]# getenforce
disabled
[root@spring ~]# systemctl stop firewalld
[root@spring ~]# !ipt
iptables -nvl
chain
input (policy accept
0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
chain
forward (policy accept
0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
chain
output (policy accept
0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
[root@spring ~]#

global_defs notification_email_from [email protected] smtp_server 127.0 .0.1 smtp_connect_timeout 30 router_id lvs_devel }vrrp_script chk_nginx vrrp_instance vi_1 virtual_ipaddress track_script

}

編寫監控指令碼/usr/local/sbin/check_ng.sh，加入以下內容

#時間變數，用於記錄日誌
d=`date --date today +%y%m%d_%h:%m:%s`
#計算nginx程序數量
n=`ps -c nginx --no-heading|wc -l`
#如果程序為0，則啟動nginx，並且再次檢測nginx程序數量，
#如果還為0，說明nginx無法啟動，此時需要關閉keepalived
if [ $n
-eq"0" ]; then
systemctl start nginx
n2=`ps -c nginx --no-heading|wc -l`
if [ $n2
-eq"0"  ]; then
echo
"$d nginx down,keepalived will stop" >> /var/log/check_ng.log
systemctl stop keepalived
fifi

並修改為755的許可權，啟動服務。

[root@spring ~]# chmod 755 !$
chmod
755 /usr/local/sbin//check_ng.sh
[root@spring ~]# systemctl start keepalived
[root@spring ~]# ps aux |grep keepalived
root       1516
0.00.0
120740
1408 ?        ss   01:01
0:00 /usr/sbin/keepalived -d
root       1517
0.00.1
127476
3276 ?        s    01:01
0:00 /usr/sbin/keepalived -d
root       1518
0.10.1
131780
3108 ?        s    01:01
0:00 /usr/sbin/keepalived -d
root       1575
0.00.0
112676
976 pts/0    s+   01:02
0:00
grep --color=auto keepalived
[root@spring ~]#

測試訪問主ip顯示的是master，訪問從ip顯示backup ,訪問192.168.244.100顯示的資訊和主上是一樣的。

iptables -i output -p vrrp -j drop

在master上關閉keepalived服務後再檢視ip，發現192.168.244.100ip不在master上了，而是去到了backup上面。當啟動master上的keepalived服務後，vip又回到了master上

Linux集群架構

linux集群架構 keepalived高可用

Mycat集群架構

MYSQL集群架構

Linux集群架構

linux集群架構 keepalived高可用

Mycat集群架構

MYSQL集群架構

相關推薦