負載均衡服務之HAProxy基礎配置（三）

　　前文咱們聊到了haproxy的代理配置段中比較經常使用的配置指令的用法以及說明，回顧請參考http://www.javashuo.com/article/p-fvsiehqt-t.html；今天咱們來講說haproxy的狀態頁的配置，以及基於cookie實現的會話保持配置；

　　haproxy和nginx同樣，都有一個狀態頁，這個頁面對於運維人員來講是一個比較重要的頁面，裏面包含了haproxy代理的後端服務器的各類指標，一般咱們要了解後端主機是否健康，當前負載狀況，咱們能夠經過狀態頁去了解；haproxy的狀態頁配置起來很簡單，用stats enable指令去開啓便可；

　　stats enable：開啓狀態頁；該指令能夠配置在frontend或者listen或者backend，若是定義在backend中，那麼咱們必需要用前端去調用該banckend纔可以看到狀態頁，因此一般咱們都定義在listen中或者frontend中；具體示例以下

　　示例：定義在backend中

　　提示：定義在backend中必需要用frontend去調用該backend；

　　示例：定義在frontend中

　　示例：定義在listen中

　　提示：以上三種方式都不影響訪問狀態頁面，推薦配置在fonrtend或listen中；

　　配置好stats enable參數後，重啓haproxy，咱們就能夠經過瀏覽器訪問haproxy所在主機的對應端口，我這裏監聽在81端口上，因此訪問http://192.168.0.22:81/haporxy?stats就能夠訪問到狀態頁；以下

　　提示：之因此訪問/haproxy?stats這個uri纔可以訪問到狀態頁，是由於咱們沒有在配置文件中明確指定把狀態頁綁定到那個uri上，默認狀況不指定就是這個/haproxy?stats，固然咱們若是要指定須要用stats uri <prefix>來指定對應的rui便可，以下

　　 stats uri <prefix>：自定義stats page uri，默認值：/haproxy?stats

　　示例：更改狀態也都uri

　　提示：以上配置表示訪問狀態頁，的uri爲/admin??status

　　測試：用瀏覽器訪問81端口上的/admin??status這個uri看看是否可以訪問到狀態頁？

　　提示：能夠看到咱們更改了uri後，默認的uri就不能夠訪問了，必須鍵入咱們指定uri才能夠被訪問到，這在必定程度上下降了任何人訪問狀態頁的風險；

　　stats auth <user>:<passwd>：配置狀態頁面認證的帳號和密碼，可以使用屢次；默認：no authentication，表示不驗證

　　示例：配置狀態頁只容許admin用戶訪問而且密碼爲admin123.com

　　提示：以上配置表示開啓狀態頁的認證功能，而且添加admin爲用戶名，admin123.com爲密碼

　　測試：如今咱們訪問狀態頁，看看是否須要驗證？

　　提示：能夠看到咱們如今訪問狀態頁，須要咱們提供用戶名和密碼了，這相對於前面的配置，對於狀態頁的獲取更加安全了；

　　stats realm <realm>：設置認證時彈出輸入用戶名密碼的提示信息；

　　tats refresh <delay>：設置自動刷新時長；

　　示例：

　　提示：以上配置表示設定彈出輸入用戶名和密碼的提示，設置自動刷新時長爲每4秒自動刷新一次

　　測試：重啓haproxy，看看對應配置是否生效

　　提示：能夠看到咱們配置的輸入用戶名和密碼提示的字符串和自動刷新頁都實現了，這裏說一下，設定提示字符串須要把空白字符經過「\」轉義，不然不會生效，加引號好像都不能夠；

　　stats admin { if | unless } <cond>：啓用stats page中的管理功能

　　示例：配置能夠在狀態頁管理後端主機的權限；一般會經過後面的acl去控制，我這裏爲了演示方便，就用TRUE這個內置的ACL

　　提示：以上配置表示開啓狀態頁管理功能，在條件爲真的狀況下，if TRUE表示一直爲真，這意味着只要登陸狀態頁，就有管理後端主機的權限；

　　測試：

　　提示：能夠看到咱們能夠把後端主機的狀態任意調整；

　　stats hide-version：隱藏版本

　　示例：隱藏haproxy狀態也的版本信息

　　測試：登陸狀態頁看看是否還有版本信息？

　　到此狀態頁的配置相關指令說完了，接下來咱們來講說狀態頁裏邊的內容；

　　提示：pid = 11712 (process #4, nbproc = 4) #pid爲當前pid號，process爲當前進程號，nbproc和nbthread爲一共多少進程和每一個進程多少個線程（多線程須要在1.7以上的版本才支持）；uptime = 0d 0h08m17s #啓動了多長時間；system limits: memmax = unlimited; ulimit-n = 8035表示系統資源限制：內存/最大打開文件數/；maxsock = 8035; maxconn = 4000; maxpipes = 0表示最大socket鏈接數/單進程最大鏈接數/最大管道數maxpipes；current conns = 1; current pipes = 0/0; conn rate = 1/sec；表示當前鏈接數/當前管道數/當前鏈接速率；Running tasks: 1/8; idle = 100 %表示運行的任務/當前空閒率；

　　active UP：綠色表示在線服務器； backup UP：天藍色表示標記爲backup的服務器；active UP, going down：淡黃色表示監測未經過正在進入down過程；backup UP, going down：深紫色表示備份服務器正在進入down過程；active DOWN, going up：黃色表示down的服務器正在進入up過程；backup DOWN, going up：淺紫色表示備份服務器正在進入up過程；active or backup DOWN：粉紅色表示在線的服務器或者是backup的服務器已經轉換成了down狀態； not checked：灰色表示標記爲不監測的服務器（沒有對它作健康狀態監測）；active or backup DOWN for maintenance (MAINT) ：棕色表示active或者backup服務器認爲下線的；active or backup SOFT STOPPED for maintenance ：深藍色表示active或者backup被認爲軟下線(人爲將weight改爲0)；

　　提示：session rate(每秒的鏈接會話信息)中的指標有cur,max,limit;其中cur表示每秒的當前會話數量；max表示每秒的最大會話數量；limit表示每秒新的會話限制量；sessions(會話信息)，cur:表示當前會話量；max:表示最大會話量；limit: 表示限制會話量；Total:表示總共會話量；LBTot:表示選中一臺服務器所用的總時間；Last：表示和服務器的持續鏈接時間；Bytes(流量統計)：In表示網絡的字節輸入總量；Out表示網絡的字節輸出總量；Denied(拒絕統計信息)：Req表示拒絕請求量；Resp表示拒絕恢復量；Errors(錯誤統計信息)：Req表示錯誤請求量；conn表示錯誤鏈接量；Resp表示錯誤響應量；Warnings(警告統計信息)：Retr表示從新嘗試次數；Redis表示再次發送次數；Server(real server信息)：Status表示後端server的狀態，包含UP和DOWN；LastChk表示持續監測後端服務器的時間，其中L4OK表示基於4層tcp檢查OK，L7OK表示基於7層應用層檢查OK；Wght表示權重；Act表示活動連接數量；Bck表示備份的服務器數量；Chk表示心跳監測時間；Dwn表示後端服務器鏈接後都是DOWN的數量；Dwntme表示總的downtime時間；Thrtle表示server的狀態；

　　瞭解了上面的狀態頁信息說明後，接下來咱們來聊一聊haproxy基於cookie作會話保持；

　　首先咱們要清楚什麼叫cookie?它的主要做用是幹什麼的？衆所周知http是無狀態的，所謂無狀態就是前一秒客戶端訪問服務端，後一秒同一客戶端訪問服務端，服務端是沒法判斷是否是同一客戶端；就至關於服務端沒有任何能力記住客戶端；這樣一來就存在一個問題；若是是一須要驗證的網站，若是服務端不能辨別客戶端身份，這意味着它不可以辨認究竟是哪一個客戶端登陸了，這樣一來用戶每刷新一次網頁，服務端就會要求客戶端從新登陸；這很顯然不是正常的邏輯；爲了解決這樣的問題，服務端每當客戶端登陸的時候，就會檢查請求報文中是否攜帶cookie信息；若是沒有攜帶cookie服務端在響應客戶端的時候就會在響應報文中添加一個set-cookie的首部，意思是告訴客戶端，這是你的cookie；客戶端拿到服務端的響應的同時，它會自動的把服務端發來的cookie保存到一個特定的地方，下次客戶端再次訪問服務端的時候，就會把上次服務器發送過來的cookie信息帶上去訪問服務器；這樣一來服務端收到客戶端的請求，一看請求報文中的cookie信息，服務端就知道這個請求是那個用戶發送過來的；這樣一來服務端就經過cookie來辨認客戶端了；這也是cookie的主要做用；一般狀況下保存在客戶端的叫cookie;在服務端一側相似cookie的功能的東西咱們叫session；一般二者經過某些信息來對應的；好比在客戶端cookie信息裏記錄了服務端上的session的號碼；當客戶端再次訪問服務端時，就會把cookie中的信息發送給服務端；服務端收到客戶端發送過來的cookie就會去找對應的session；從而實現了，服務端知道對應客戶端上次的操做；cookie是有時限性的；一般在有效的時間內去訪問服務端，服務端都可以準確的辨認客戶端；過時之後，服務端會從新給客戶端發送cookie信息；

　　從上面的描述，咱們不難理解，cookie就是用來讓服務端辨識客戶端的一種機制；而對於haproxy來說，基於cookie來作會話保持的原理就是經過對後端服務器響應報文中的cookie信息中添加(或覆蓋的方式)一個鍵值對，在客戶端下次訪問時，檢查對應cookie首部的信息，從而讓haproxy可以判斷把該請求調度在那個後端服務器上；一般咱們會在server上設置一個cookie的值，在listen或backend中設置一個cookie的鍵，明確說明以怎樣的方式設置cookie的鍵；經過listen或backend中設置的cookie的鍵結合server後面的cookie的值組成的cookie信息，從而實現不一樣的cookie信息調度到不一樣的server上去；

　　示例：

　　提示：以上cookie COOKIE insert nocache表示在後端服務器響應報文首部中添加一個cookie的名稱爲COOKIE，而對應cookie的值就來源於後面server中的cookie的值；nocache表示該cookie不被共有緩存系統緩存；

　　測試：重啓haproxy，用瀏覽器訪問看看響應首部有什麼變化

　　提示：能夠看到當客戶端第一次訪問時，響應首部set-Cookie中就會設置一個COOKIE=web1的值；這個值就是咱們剛纔在haproxy配置的，從這個值上看，咱們本次訪問被調度到web1上了，以後咱們再次訪問時，就不會被調度到其餘服務器上，在cookie過時以前始終都會被調度到web1上響應；這是由於下次咱們訪問時，會自動把這個cookie信息攜帶上；以下

　　提示：正是由於咱們攜帶的cookie信息是COOKIE=web1和haproxy上的web1上的cookie的值相同，因此咱們只要攜帶COOKIE=web1就會被調度到web1上；

　　用curl 模擬cookie信息訪問不一樣後端服務器

　　提示：經過不一樣的cookie信息，就能夠訪問到不一樣後端server了；這樣就實現了基於cookie信息來把相同cookie的請求發送給同一後端server的目的；實現了會話保持；