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

　　前文咱們聊了下haproxy的global配置段中的經常使用參數的說明以及使用，回顧請參考http://www.javashuo.com/article/p-cjtbdvki-ca.html；今天咱們來講說haproxy的代理配置段中比較重要的參數配置的用法；

　　代理配置段中分三段配置，第一段是defaults配置段，這一段咱們在上一篇博客中也說過，主要用於定義一些默認參數配置；第二段是frontend配置段，該段主要用來定義haporxy面向客戶端怎樣提供服務的；好比監聽在那個地址的那個端口啊，調度那個後端服務器組呀等等；第三段就是後端服務器的配置段，一般frontend和backend是聯合使用，也就是說frontend必須調用一個已經定義好的backend這樣纔可以徹底的把用戶的請求調度到對應服務器或者服務器組上；而對於listen來說，它更像一個代理的角色，它既能夠定義前端對於用戶端監聽地址信息，同時它也能定義後端server的屬性；簡單講listen指令融合了frontend和backend的功能；瞭解瞭如何定義前端監聽地址以及後端被代理的server的方式後，接下來咱們一一來看下代理配置段中的配置；

　　defaults裏的配置

　　mode：該指令用於指定haporxy的工做類型的；http表示haproxy基於http協議代理後端服務器，這也是默認haproxy的工做類型；若是咱們在後端backend或listen中沒有配置haporxy的工做類型，默認就會繼承defaults裏的配置；tcp表示haproxy基於tcp協議代理後端服務器響應客戶端請求；

　　option redispatch ：當後端server宕機後，強制把請求定向到其餘健康的服務器上；正是由於這個參數，就確保了用戶端請求不會被調度到一個宕機的服務器上；

　　示例：咱們把option redispatch 這個配置註釋掉，重啓haproxy，而後把後端容器給停掉一臺，看看haproxy會不會把對應的請求調度到停掉的server上呢？

 　　提示：咱們只是註釋了option redispatch 這段配置；對於後端服務器並無人爲手動的去修改；正常狀況下，三臺服務器若是都是正常的狀況，是可以輪詢的方式響應客戶端請求的；如今咱們把後端服務器停一臺看看用戶的請求會不會調度到停掉的那臺服務器上呢？

 　　提示：如今咱們能夠看到web2的狀態是退出狀態，不可以響應客戶端的請求的；接下來咱們用瀏覽器訪問haproxy對外提服務的IP地址和端口；看看是否把用戶請求調度到宕機的主機上

 　　提示：能夠看到haproxy仍是把用戶端請求往宕機的主機上調度；咱們把option  redispatch 配置打開，而後重啓haproxy，在看看會不會把用戶請求調度到宕機的主機上

 　　提示：咱們打開option redispatch 配置，而後重啓haproxy；對於web2如今仍是宕機的狀態，咱們再用瀏覽器訪問，看看此次會不會把用戶請求調度到宕機的web2上呢

 　　提示：咱們把option redispatch 配置加上後，咱們用瀏覽器訪問haproxy的80端口，它不會把用戶端請求調度到web2上去，緣由就是由於檢測web2沒有經過，強制把請求調度到下一個服務器上去了；之因此咱們看到中間有一段時間要等，是由於haproxy在對web2進行檢測；

　　option abortonclose：當服務器負載很高的時候，自動結束掉當前隊列處理比較久的連接；

　　option http-keep-alive 60：開啓會話保持，並設置時長爲60s

　　option forwardfor：開啓IP透傳；這個參數的意思是把客戶端的源ip信息經過X-Forwarded-For首部傳給後端server，後端server可經過撲捉haproxy發來的請求報文，把對應X-Forwarded-For首部的值記錄下來；一般須要後端服務器更改日誌格式，把對應首部的值加入到日誌中顯示；

　　示例：配置後端server記錄haproxy發來的請求報文中X-Forwarded-For首部的值；

 　　提示：咱們在web1上修改了httpd的日誌格式，讓第一個字段記錄X-Forwarded-For首部的值；而後讓httpd重讀配置文件；接下來咱們就能夠用瀏覽器訪問haproxy，看看web1是否可以把客戶端的源ip記錄下來

　　提示：能夠看到當haproxy把咱們的請求調度到web1上時，對應web1的日誌就會把X-Forwarded-For的值記錄下來；這個首部的值就是記錄客戶端的源ip地址的；這樣一來咱們後端server上的日誌就再也不只有haproxy代理的的地址了；

　　timeout connect 60s：轉發客戶端請求到後端server的最長鏈接時間；這個時間是定義代理鏈接後端服務器的超時時長；

　　timeout server 600s ：轉發客戶端請求到後端服務端的超時超時時長；這個時間是服務端響應代理的超時時長；

　　timeout client 600s ：與客戶端的最長空閒時間；

　　timeout http-keep-alive 120s：session 會話保持超時時間，範圍內會轉發到相同的後端服務器；

　　timeout check 5s：對後端服務器的檢測超時時間；

　　retries 3：定義重試次數；

　　maxconn  3000：server的最大鏈接數（一般這個會配置在各server後面，用來指定該server的最大鏈接數）

　　以上就是haproxy defaults配置段的經常使用配置說明和使用；接下來咱們來講一下frontend 配置段和backend配置段

　　frontend配置段裏的指令配置

　　bind:該指令用於指定綁定IP和端口的，一般用於frontend配置段中或listen配置段中；用法是bind [IP]:<PORT>,……

　　示例：

　　提示：以上配置表示前端監聽80端口和8080端口，這兩個端口均可以把用戶端請求代理到後端指定的服務器組上進行響應；

　　測試：重啓haproxy 用瀏覽器訪問192.168.0.22：8080端口，看看是否可以響應？

　　提示：能夠看到咱們用瀏覽器訪問8080也是可以正常響應的；

　　除此之外，前端監聽端口咱們也能夠不用bind參數指定 咱們直接在frontend 或listen名字後面加要監聽的地址和端口便可，以下所示

　　提示：listen的配置也是支持以上兩種的形式去監聽端口的；一般不寫IP地址表示監聽本機因此ip地址對應的端口；

　　balance：指定後端服務器組內的服務器調度算法；這個指令只能用於listen和backend或者defaults配置段中；

　　　　roundrobin：動態輪詢；支持權重的運行時調整，支持慢啓動，每一個後端中最多支持4095個server；什麼意思呢？動態調整權重就是說不重啓服務的狀況下調整權重；慢啓動說的是，前端的流量不會一會兒所有給打進來，而是一部分一部分的打到後端服務器上；這樣能夠有效防止流量過大時一會兒把後端服務器壓垮的狀況；後端最多支持4095個server表示在一個backend或listen中使用該算法最多隻能定義4095個server；一般對於生產環境這個也是夠用了；

　　　　static-rr：靜態輪詢，不支持權重的運行時調整，不支持慢啓動；這也是靜態算法的肯定；但這種算法對後端server沒有限制；

　　　　leastconn：最少鏈接算法；該算法本質上同static-rr沒有太多的不一樣，一般狀況下static-rr用於短鏈接場景中；而leastconn多用於長鏈接的場景中，如MySQL、LDAP等；

　　　　first：根據服務器在列表中的位置，自上而下進行調度；前面服務器的鏈接數達到上限，新請求才會分配給下一臺服務；

　　　　source：源地址hash算法；相似LVS中的sh算法；hash類的算法動態與否取決於hash-type的值；若是咱們定義hash-type的值爲map-based（除權取餘法）就表示該算法是靜態算法，靜態算法就不支持慢啓動，動態調整權重；若是hash-type的值是consistent（一致性哈希）就表示該算法是動態算法，支持慢啓動，動態權重調整；

　　　　uri：對URI的左半部分作hash計算，並由服務器總權重相除之後派發至某挑出的服務器；這裏說一下一個完整的rul的格式；<scheme>://[user:password@]<host>:<port>[/path][;params][?query][#frag]其中scheme，host，port這三項是必須有的，其餘無關緊要；這裏說的uri就是指[/path][;params][?query][#frag]這一部分，而uri的左半部份指的是[/path][;params]；因此uri算法是對用戶請求的資源路徑+參數作hash計算；

　　　　url_param：對用戶請求的uri的<params>部分中的參數的值做hash計算，並由服務器總權重相除之後派發至某挑出的服務器；一般用於追蹤用戶，以確保來自同一個用戶的請求始終發往同一個Backend Server；

　　　　hdr(<name>)：對於每一個http請求，此處由<name>指定的http首部將會被取出作hash計算； 並由服務器總權重相除之後派發至某挑出的服務器；沒有有效值的會被輪詢調度； 如hdr(Cookie)使用cookie首部作hash，把同一cookie的訪問始終調度到某一臺後端服務器上；

　　示例：使用uri算法，並指定使用一致性hash算法

　　提示：這樣配置後，用戶訪問80端口的某一個uri始終會發往同一臺服務器上；不論是那個用戶去訪問都會被調度到同一臺服務器上進行響應

　　咱們在後端服務器上提供一些默認的頁面，分別用不一樣的客戶主機去訪問相同的rul看看haproxy會怎麼調度？

 　　提示：在三個容器內部分別新建了一個test.html的文件，其內容都是不相同的；接下來咱們用瀏覽器訪問/test.html看看會怎麼調度

　　提示：能夠看到咱們不論是用windows上的瀏覽器訪問仍是用Linux中的curl訪問 都是被調度到web1上去了；其餘算法我這裏就不過多去測試了，有興趣的小夥伴可本身動手去試試，看看效果；

　　default_backend <backend>：設定默認的backend，用於frontend中；

　　use_backend <backend>：調用對應的backend，用於frontend中；

　　示例：

　　提示：以上配置表示用戶訪問80端口或8081端口，都會被調度到webservs這個後端服務器組上進行響應；

　　server <name> <address>[:[port]] [param*]：定義後端主機的各服務器及其選項；name表示服務器在haproxy上的內部名稱；出如今日誌及警告信息中；address表示服務器地址，支持使用主機名；port：端口映射；省略時，表示同bind中綁定的端口；param表示參數；經常使用的參數有以下幾個：

　　maxconn <maxconn>：當前server的最大併發鏈接數；

　　backlog <backlog>：當前server的鏈接數達到上限後的後援隊列長度；

　　backup：設定當前server爲備用服務器；和nginx裏的sorry server 是同樣的；

　　cookie <value>：爲當前server指定其cookie值，用於實現基於cookie的會話黏性；

　　disabled：標記爲不可用；至關於nginx裏的down;

　　redir <prefix>：將發往此server的全部GET和HEAD類的請求重定向至指定的URL；

　　weight <weight>：權重，默認爲1; 

　　on-error <mode>：後端服務故障時採起的行動策略；策略有以下幾種：

　　　　fastinter：表示縮短健康狀態檢測間的時長；

　　　　fail-check：表示即健康狀態檢測失敗，也要檢測；這是默認策略；

　　　　sudden-death:模擬一個致命前的失敗的健康檢查，一個失敗的檢查將標記服務器關閉，強制fastinter

　　　　mark-down：當即標記服務器不可用，並強制fastinter；

　　check：對當前server作健康狀態檢測；
　　　　addr ：檢測時使用的IP地址；
　　　　port ：針對此端口進行檢測；
　　　　inter <delay>：連續兩次檢測之間的時間間隔，默認爲2000ms;
　　　　rise <count>：連續多少次檢測結果爲「成功」才標記服務器爲可用；默認爲2；
　　　　fall <count>：連續多少次檢測結果爲「失敗」才標記服務器爲不可用；默認爲3；

　　示例：

 

　　提示：以上配置表示對web1進行健康狀態檢測 每隔3000毫秒檢測一次，檢測2次失敗就馬上標記爲不可用，並強制縮短檢測間隔時長；權重爲2，意思是該服務器被調度兩次，其餘服務器調度一次；最大鏈接爲1000；web2配置爲backup角色，只有當web1和web3宕機後，web2才被調度；訪問web3的請求直接重定向到http://nginx.org上響應；接下來咱們若是訪問haproxy的80或8081端口，應該是能夠訪問到web1和web3；若是web1和web3宕機後，web2就會被調度；

　　測試：在web1和web3都正常的狀況下，看看web2是否被調度？

　　提示：能夠看到web2是沒有被調度的，web1被調度兩次後，直接跳過web2，調度web3去了；

　　測試：把web1和web3停了，看看web2是否被調度？

　　提示：咱們把web1和web3給停了，用瀏覽器訪問，它仍是跳轉了；這說明redir不關心所在server是否存活，它都會作跳轉，只不過所在server存活的狀況下，用戶請求偶爾幾回會不跳轉，但必定會有跳轉的狀況；這樣來講吧，只要有跳轉所在server，且沒有作健康狀態檢測，那麼無論該組是否有存活server backup都是不能被激活的；要想backup被激活必須讓haproxy知道對應後端服務器組裏是否有活躍的服務器，若是有，它就不會激活backup，若是沒有就會激活；但如今haproxy不知道，緣由是web3壓根沒有作健康狀態檢測；因此要想激活backup，咱們須要在web3上配置一個check便可；以下

　　提示：咱們在web3上加入健康狀態檢測後服務可以正常起來；這樣配置後，backup服務器就會被激活，以下

　　如今咱們把web3啓動起來，看看它是否還會跳轉呢？

　　提示：能夠看到咱們把web3啓動起來，對應的跳轉就失效了；從上面的結果我這裏總結了一條，redir和check建議不要一塊兒用，一塊兒用的話，對應redir就會失效；