前文我們聊了下haproxy的global配置段中的常用引數的說明以及使用，回顧請參考https://www.cnblogs.com/qiuhom-1874/p/12763245.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就會失效；
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/96277.html
標籤：Linux
上一篇：折騰 2 年多！我們終于見面了！
下一篇：linux基礎命令一