h.部署前端haproxy而且用keepalived高可用javascript
先在node1上部署好haproxy,然後在安裝好keepalived,把node1上的配置複製到node11上。css
安裝haproxy,在base源下有html
# yum install -yhaproxy前端
haproxy的配置:java
global settings: 全局配置段node
主要用於定義haproxy進程自身的工做特性;web
proxies: 代理配置段正則表達式
事先定義好一組後端服務器,事先定義好一組前端監聽的地址,然後將他們關聯起來算法
backend: 後端服務器組vim
frontend: 定義面向客戶的監聽的地址和端口,以及關聯到的後端服務器組;
listen: 組合方式直接定義frontend及相關的backend的一種機制;
defaults: 定義默認配置;
haproxy的部分配置說明 /etc/haproxy/haproxy.cnf
使用本機的facility來記錄日誌,就不用發往服務器了,
# local2.* /var/log/haproxy.log 把這項寫到/etc/rsyslog.conf中
log 127.0.0.1 local2 日誌發往服務器的哪裏?使用facility的local2來記錄日誌,也須要在/etc/rsyslog.conf中指明記錄到那個位置,沒有寫的話則記錄到/var/log/messages文件中,在rsyslog啓動時,須要監聽在udp或者tcp的端口上
# Provides UDPsyslog reception
#$ModLoad imudp
#$UDPServerRun 514
# Provides TCPsyslog reception
#$ModLoad imtcp
#$InputTCPServerRun514 /etc/rsyslog.conf中都註釋了,因此記錄不了日誌,要啓用記錄日誌,這裏要取消對tcp和udp的註釋
+++++++++
具體實現
啓用/etc/haproxy/haproxy.cnf中
log 127.0.0.1 local2
在/etc/rsyslog.conf中啓用
# Provides UDPsyslog reception
$ModLoad imudp
$UDPServerRun 514
# Include allconfig files in /etc/rsyslog.d/
$ModLoad imtcp
$InputTCPServerRun514
再添加
local2.* /var/log/haproxy.log
性能調整相關的參數
-maxconn <number>:設定每一個haproxy進程所接受的最大併發鏈接數,其等同於命令行選項「-n」;「ulimit -n」自動計算的結果正是參照此參數設定的;
- spread-checks<0..50, in percent>:在haproxy後端有着衆多服務器的場景中,在精確的時間間隔後統一對衆服務器進行健康情況檢查可能會帶來意外問題;此選項用於將其檢查的時間間隔長度上增長或減少必定的隨機時長;
- tune.maxaccept<number>:設定haproxy進程內核調度運行時一次性能夠接受的鏈接的個數,較大的值能夠帶來較大的吞吐率,默認在單進程模式下爲100,多進程模式下爲8,設定爲-1能夠禁止此限制;通常不建議修改;
代理相關的配置能夠以下配置段中。
name是必須指定的
- defaults <name>
- frontend <name>
- backend <name>
- listen <name>
全部代理的名稱只能使用大寫字母、小寫字母、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)。此外,ACL名稱會區分字母大小寫。
frontend <name>IP:PORT
use_backend
default_backend
backend <name>
balance<scheduler> 指明調度方法
server <name>IP:PORT [check] check對後端服務器作健康檢測
...
listen <name> IP:PORT
balance 指明調度方法
server
server
defaults 定義默認配置
balance
balance<algorithm> [ <arguments> ]
balance url_param<param> [check_post [<max_wait>]]
定義負載均衡算法,可用於「defaults」、「listen」和「backend」。<algorithm>用於在負載均衡場景中挑選一個server,其僅應用於持久信息不可用的條件下或須要將一個鏈接從新派發至另外一個服務器時。支持的算法有:
roundrobin:基於權重進行輪叫,在服務器的處理時間保持均勻分佈時,這是最平衡、最公平的算法。此算法是動態的,這表示其權重能夠在運行時進行調整,不過,在設計上,每一個後端服務器僅能最多接受4128個鏈接;
static-rr:基於權重進行輪叫,與roundrobin相似,可是爲靜態方法,在運行時調整其服務器權重不會生效;不過,其在後端服務器鏈接數上沒有限制;
leastconn:新的鏈接請求被派發至具備最少鏈接數目的後端服務器;在有着較長時間會話的場景中推薦使用此算法,如LDAP、SQL等,其並不太適用於較短會話的應用層協議,如HTTP;此算法是動態的,能夠在運行時調整其權重;
source:將請求的源地址進行hash運算,並由後端服務器的權重總數相除後派發至某匹配的服務器;這可使得同一個客戶端IP的請求始終被派發至某特定的服務器;不過,當服務器權重總數發生變化時,如某服務器宕機或添加了新的服務器,許多客戶端的請求可能會被派發至與此前請求不一樣的服務器;經常使用於負載均衡無cookie功能的基於TCP的協議;其默認爲靜態,不過也可使用hash-type修改此特性;
uri:對URI的左半部分(「問題」標記以前的部分)或整個URI進行hash運算,並由服務器的總權重相除後派發至某匹配的服務器;這可使得對同一個URI的請求老是被派發至某特定的服務器,除非服務器的權重總數發生了變化;此算法經常使用於代理緩存或反病毒代理以提升緩存的命中率;須要注意的是,此算法僅應用於HTTP後端服務器場景;其默認爲靜態算法,不過也可使用hash-type修改此特性;
url_param:經過<argument>爲URL指定的參數在每一個HTTP GET請求中將會被檢索;若是找到了指定的參數且其經過等於號「=」被賦予了一個值,那麼此值將被執行hash運算並被服務器的總權重相除後派發至某匹配的服務器;此算法能夠經過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器,除非服務器的總權重發生了變化;若是某請求中沒有出現指定的參數或其沒有有效值,則使用輪叫算法對相應請求進行調度;此算法默認爲靜態的,不過其也可使用hash-type修改此特性;
hdr(<name>):對於每一個HTTP請求,經過<name>指定的HTTP首部將會被檢索;若是相應的首部沒有出現或其沒有有效值,則使用輪叫算法對相應請求進行調度;其有一個可選選項「use_domain_only」,可在指定檢索相似Host類的首部時僅計算域名部分(好比經過www.magedu.com來講,僅計算magedu字符串的hash值)以下降hash算法的運算量;此算法默認爲靜態的,不過其也可使用hash-type修改此特性;
ACL
haproxy的ACL用於實現基於請求報文的首部、響應報文的內容或其它的環境狀態信息來作出轉發決策,這大大加強了其配置彈性。其配置法則一般分爲兩步,首先去定義ACL,即定義一個測試條件,然後在條件獲得知足時執行某特定的動做,如阻止請求或轉發至某特定的後端。定義ACL的語法格式以下。
acl<aclname> <criterion> [flags] [operator] <value> ...
<aclname>:ACL名稱,區分字符大小寫,且其只能包含大小寫字母、數字、-(鏈接線)、_(下劃線)、.(點號)和:(冒號);haproxy中,acl能夠重名,這能夠把多個測試條件定義爲一個共同的acl;
<criterion>:測試標準,即對什麼信息發起測試;測試方式能夠由[flags]指定的標誌進行調整;而有些測試標準也能夠須要爲其在<value>以前指定一個操做符[operator];
[flags]:目前haproxy的acl支持的標誌位有3個:
-i:不區分<value>中模式字符的大小寫;
-f:從指定的文件中加載模式;
--:標誌符的強制結束標記,在模式中的字符串像標記符時使用;
<value>:acl測試條件支持的值有如下四類:
整數或整數範圍:如1024:65535表示從1024至65535;僅支持使用正整數(若是出現相似小數的標識,其爲一般爲版本測試),且支持使用的操做符有5個,分別爲eq、ge、gt、le和lt;
字符串:支持使用「-i」以忽略字符大小寫,支持使用「\」進行轉義;若是在模式首部出現了-i,能夠在其以前使用「--」【是兩個-】標誌位;
正則表達式:其機制類同字符串匹配;
IP地址及網絡地址
同一個acl中能夠指定多個測試條件,這些測試條件須要由邏輯操做符指定其關係。條件間的組合測試關係有三種:「與」(默認即爲與操做)、「或」(使用「||」操做符)以及「非」(使用「!」操做符)。
經常使用的測試標準(criteria)
be_sess_rate(backend) <integer>
用於測試指定的backend上會話建立的速率(即每秒建立的會話數)是否知足指定的條件;經常使用於在指定backend上的會話速率太高時將用戶請求轉發至另外的backend,或用於阻止***行爲。例如:
backend dynamic
mode http
acl being_scanned be_sess_rate gt 50 若是每秒鐘會話建立數大於50個,則認爲是遭到***了
redirect location /error_pages/denied.html if being_scanned 若是說遭到***,則將請求內容重定向到/error_pages/denied.html上
fe_sess_rate(frontend) <integer>
用於測試指定的frontend(或當前frontend)上的會話建立速率是否知足指定的條件;經常使用於爲frontend指定一個合理的會話建立速率的上限以防止服務被濫用。例以下面的例子限定入站郵件速率不能大於50封/秒,全部在此指定範圍以外的請求都將被延時50毫秒。
frontend mail
bind :25
mode tcp
maxconn 500
acl too_fast fe_sess_rate ge 50
tcp-request inspect-delay 50ms 將速率大於50的都延遲50ms
tcp-request content accept if ! too_fast 若是請求速率沒有超過50,則accept
tcp-request content accept if WAIT_END 等待結束了,也能夠接收進來
訪問速率值設置須要注意,不要把正常的都阻止了
hdr(header) <string>
用於測試請求報文中的全部首部或指定首部是否知足指定的條件;指定首部時,其名稱不區分大小寫,且在括號「()」中不能有任何多餘的空白字符。測試服務器端的響應報文時可使用shdr()。例以下面的例子用於測試首部Connection的值是否爲close。
hdr(Connection) -i close
method <string>
測試HTTP請求報文中使用的方法。
path_beg <string>
用於測試請求的URL是否以<string>指定的模式開頭。下面的例子用於測試URL是否以/static、/p_w_picpaths、/javascript或/stylesheets頭。
acl url_static path_beg -i /static /p_w_picpaths /javascript/stylesheets
path_end <string>
用於測試請求的URL是否以<string>指定的模式結尾。例如,下面的例子用戶測試URL是否以jpg、gif、png、css或js結尾。
aclurl_static path_end -i .jpg .gif .png .css .js
在acl中使用同一個名字是能夠的
hdr_beg <string>
用於測試請求報文的指定首部的開頭部分是否符合<string>指定的模式。例如,下面的例子用記測試請求是否爲提供靜態內容的主機img、video、download或ftp。
acl host_static hdr_beg(host) -i img. video. download. ftp.
hdr_end <string>
用於測試請求報文的指定首部的結尾部分是否符合<string>指定的模式。例如,下面的例子用記測試請求是否爲
hdr_reg (header) <regex> 對指定請求的值作正則表達式匹配
path_reg <regex> 對請求路徑作做則表達式匹配的
這裏要實現動靜分離,經過haproxy的ACL功能來實現,動態內容分發到node4和node5,靜態內容分發到varnish上。
配置內容:
frontend main
maxconn 6000
bind :80
acl url_static path_beg -i /p_w_picpaths /video /music 若是這裏加了/,則全部請求都被定位到此處
acl url_static path_end -i .jpg .html .css .png .gif .txt
use_backend static if url_static
default_backend webapp
backend static
balance uri
server static1 192.168.21.178check port 80
server static2 192.168.21.167check port 80
server h1 127.0.0.1 backup port 8080
backend webapp
balance source
server s1 192.168.21.166check port 80 maxconn 4000 weight 2
server s2 192.168.21.150 check port 80 maxconn 4000 weight 2
server h1 127.0.0.1:8080 backup
stats enable 顯示狀態頁的
stats hide-version
stats uri /hap?stats
stats scope .
stats realm HAproxy\ Statistic
stats auth look:look
stats admin ifTRUE
keepalived的實現
keepalived:主要實如今兩個或多個節點之間實現VRRP協議的,也即運行keepalived,keepalived能夠實現VRRP功能
vrrp就是將兩個或兩個以上的物理路由設備定義成一個虛擬的路由器,此時稱爲路由組,這一組路由設備共同聯合起來構建成虛擬路由,在虛擬路由上配置一個vip和與vip共同對應vmac,這一組的路由器上,每個路由器都有對應的優先級,每一節點剛開始都是初始化的,然後通告本身的優先級,最後經過優先級來肯定優先級最高的做爲主節點,其餘的節點都爲備節點,只有當主節點宕機時,其餘節點就會把主節點上vip等資源搶到自身主機,由此在末端主機上只需配置一個網關,指向虛擬ip,這時就實現了路由協議的高可用效果,vrrp 虛擬冗餘路由協議
兩個虛擬主機各自都安裝keepalived服務進程,keepalived進程可以經過互相通訊,經過vrrp協議的工做機制,通告優先級、選舉主節點配置ip地址
keepalived在centos 6.4以後收錄REHL繫了
#yum install –y keepalived
# rpm -qlkeepalived | less
/etc/keepalived
/etc/keepalived/keepalived.conf 配置文件
/etc/rc.d/init.d/keepalived 服務腳本,keepalived在通訊時,須要進行認證的,最好換一個多播地址,默認vrid爲51,若是不換多播地址,則通常是vrid都是惟一的
/etc/sysconfig/keepalived
/usr/bin/genhash
/usr/libexec/keepalived
/usr/sbin/keepalived
keepalived.conf配置文件中 !是註釋
# vim/etc/keepalived/keepalived.conf
! ConfigurationFile for keepalived
global_defs {
notification_email {萬一服務器掛了時,用郵件通知給誰
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_fromAlexandre.Cassen@firewall.loc
smtp_server 192.168.200.1郵件服務器,若是有郵件服務器則使用郵件服務器的地址
smtp_connect_timeout 30
router_id LVS_DEVEL
}
vrrp_instance VI_1{
state MASTER
interface eth0
virtual_router_id 21
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass keepalived
}
virtual_ipaddress {
192.168.21.152
}
notify_master "/etc/rc.d/init.d/haproxystart"
notify_backup "/etc/rc.d/init.d/haproxystop"
notify_fault "/etc/rc.d/init.d/haproxystop"
}
備節點須要修改的地方
state BACKUP 修改
priority 98 修改