haproxy(2)

二、配置HAProxy


2.1 配置文件格式


HAProxy的配置處理3類來主要參數來源:

  ——最優先處理的命令行參數,

  ——“global”配置段,用於設定全局配置參數;

  ——proxy相關配置段,如“defaults”、“listen”、“frontend”和“backend”;


2.2 時間格式


一些包含了值的參數表示時間,如超時時長。這些值一般以毫秒爲單位,但也可以使用其它的時間單位後綴。

  us: 微秒(microseconds),即1/1000000秒;

  ms: 毫秒(milliseconds),即1/1000秒;

  s: 秒(seconds);

  m: 分鐘(minutes);

  h:小時(hours);

  d: 天(days);


2.3 例子


下面的例子配置了一個監聽在所有接口的80端口上HTTP proxy服務,它轉發所有的請求至後端監聽在127.0.0.1:8000上的"server"。


  global

        daemon

        maxconn 25600


    defaults

        mode http

        timeout connect 5000ms

        timeout client 50000ms

        timeout server 50000ms


    frontend http-in

        bind *:80

        default_backend servers


    backend servers

        server server1 127.0.0.1:8080 maxconn 32


2.4 全局配置


版本:現在yum源的版本是1.5.2;兼容了1.3和1.4的版本。

      目前最新的穩定版本1.6,相對於1.5.2增加了支持http2.0的文件轉換功能。


“global”配置中的參數爲進程級別的參數,且通常與其運行的OS相關。


1.    進程管理及安全相關的參數

   - chroot <jail dir>:進程運行在此虛擬的根目錄中,haproxy運行再此目錄裏,起到安全的作用。修改haproxy的工作目錄至指定的目錄並在放棄權限之前執行chroot()操作,可以提升haproxy的安全級別,注意的是要確保指定的目錄爲空目錄且任何用戶均不能有寫權限;(不改)

   - daemon:讓haproxy以守護進程的方式工作於後臺(相當於後臺自啓動),其等同於“-D”選項的功能,當然,也可以在命令行中以“-db”選項將其禁用;

   - gid <number>:以指定的GID運行haproxy,建議使用目前

   - log  <address> <facility> [max level [min level]]:定義全局的syslog服務器,最多可以定義兩個;

   - log-send-hostname [<string>]:在syslog信息的首部添加當前主機名,可以爲“string”指定的名稱,也可以缺省使用當前主機名;

   - nbproc <number>:指定啓動的haproxy進程的個數,只能用於守護進程模式的haproxy;默認只啓動一個進程,鑑於調試困難等多方面的原因,一般只在單進程僅能打開少數文件描述符的場景中才使用多進程模式;

   - pidfile:指定pid文件

   - uid:以指定的UID身份運行haproxy進程;

   - ulimit-n:設定每進程所能夠打開的最大文件描述符數目,默認情況下其會自動進行計算,因此不推薦修改此選項;(不值)

   - user:同uid,但使用的是用戶名;

   - stats:

   - node:定義當前節點的名稱,用於HA場景中多haproxy進程共享同一個IP地址時;不是主機名,說明日誌信息由哪個節點產生的。

   - description:當前實例的描述信息;


2.    性能調整相關的參數

   - maxconn <number>:設定每個haproxy進程所接受的最大併發連接數,其等同於命令行選項“-n”;“ulimit -n”自動計算的結果正是參照此參數設定的;

   - maxpipes <number>:haproxy使用pipe完成基於內核的tcp報文重組,此選項則用於設定每進程所允許使用的最大pipe個數;每個pipe會打開兩個文件描述符,因此,“ulimit -n”自動計算時會根據需要調大此值;默認爲maxconn/4,其通常會顯得過大;

   - noepoll:在Linux系統上禁用epoll機制;

   - nokqueue:在BSD系統上禁用kqueue機制;

   - nopoll:禁用poll機制;

   - nosepoll:在Linux禁用啓發式epoll機制;

   - nosplice:禁止在Linux套接字上使用內核tcp重組,這會導致更多的recv/send系統調用;不過,在Linux 2.6.25-28系列的內核上,tcp重組功能有bug存在;

   - spread-checks <0..50, in percent>:在haproxy後端有着衆多服務器的場景中,在精確的時間間隔後統一對衆服務器進行健康狀況檢查可能會帶來意外問題;此選項用於將其檢查的時間間隔長度上增加或減小一定的隨機時長;

   - tune.bufsize <number>:設定buffer的大小,同樣的內存條件下,較小的值可以讓haproxy有能力接受更多的併發連接,較大的值可以讓某些應用程序使用較大的cookie信息;默認爲16384,其可以在編譯時修改,不過強烈建議使用默認值;

   - tune.chksize <number>:設定檢查緩衝區的大小,單位爲字節;更大的值有助於在較大的頁面中完成基於字符串或模式的文本查找,但也會佔用更多的系統資源;不建議修改;

   - tune.maxaccept <number>:設定haproxy進程內核調度運行時一次性可以接受的連接的個數,較大的值可以帶來較大的吞吐率,默認在單進程模式下爲100,多進程模式下爲8,設定爲-1可以禁止此限制;一般不建議修改;

   - tune.maxpollevents  <number>:設定一次系統調用可以處理的事件最大數,默認值取決於OS;其值小於200時可節約帶寬,但會略微增大網絡延遲,而大於200時會降低延遲,但會稍稍增加網絡帶寬的佔用量;

   - tune.maxrewrite <number>:設定爲首部重寫或追加而預留的緩衝空間,建議使用1024左右的大小;在需要使用更大的空間時,haproxy會自動增加其值;

   - tune.rcvbuf.client <number>:

   - tune.rcvbuf.server <number>:設定內核套接字中服務端或客戶端接收緩衝的大小,單位爲字節;強烈推薦使用默認值;

   - tune.sndbuf.client:

   - tune.sndbuf.server:



 * Debug相關的參數

   - debug

   - quiet


2.5 代理


代理相關的配置可以如下配置段中。


 - defaults <name>

 - frontend <name>

 - backend  <name>

 - listen   <name>


 “defaults”段用於爲所有其它配置段提供默認參數,這配置默認配置參數可由下一個“defaults”所重新設定。


 “frontend”段用於定義一系列監聽的套接字,這些套接字可接受客戶端請求並與之建立連接。


 “backend”段用於定義一系列“後端”服務器,代理將會將對應客戶端的請求轉發至這些服務器。


 “listen”段通過關聯“前端”和“後端”定義了一個完整的代理,通常只對TCP流量有用。


 所有代理的名稱只能使用大寫字母、小寫字母、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)。此外,ACL名稱會區分字母大小寫。




三、配置文件中的關鍵字參考


3.1 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修改此特性;(源地址hash,受權重總數的影響,調整會重新調度)

  uri:對URI的左半部分(“問題”標記之前的部分)或整個URI進行hash運算,並由服務器的總權重相除後派發至某匹配的服務器;這可以使得對同一個URI的請求總是被派發至某特定的服務器,除非服務器的權重總數發生了變化;此算法常用於代理緩存或反病毒代理以提高緩存的命中率;需要注意的是,此算法僅應用於HTTP後端服務器場景;其默認爲靜態算法,不過也可以使用hash-type修改此特性;

            scheme://host:port/path/to/some_resource? # 

問號之前做hash運算,作用是將同一個資源發往同一個服務器;按照請求資源的本身,有利於後面緩存服務器。受hash-type影響,使用consistent。

  url_param:通過<argument>爲URL指定的參數在每個HTTP GET請求中將會被檢索;如果找到了指定的參數且其通過等於號“=”被賦予了一個值,那麼此值將被執行hash運算並被服務器的總權重相除後派發至某匹配的服務器;此算法可以通過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器,除非服務器的總權重發生了變化;如果某請求中沒有出現指定的參數或其沒有有效值,則使用輪叫算法對相應請求進行調度;此算法默認爲靜態的,不過其也可以使用hash-type修改此特性;

            <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

            ?引導查詢條件;   #引導的整個的分段期間(錨定符);   ;引導一個參數,參數裏面有個“=”值 

            http進行調度;url裏面的參數;此算法可以通過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器;用userid的值做hash運算

  hdr(<name>):對於每個HTTP請求,通過<name>指定的HTTP首部將會被檢索;如果相應的首部沒有出現或其沒有有效值,則使用輪叫算法對相應請求進行調度;其有一個可選選項“use_domain_only”,可在指定檢索類似Host類的首部時僅計算域名部分(比如通過www.magedu.com來說,僅計算magedu字符串的hash值)以降低hash算法的運算量;此算法默認爲靜態的,不過其也可以使用hash-type修改此特性;

            header(host);cookie;(相比source更精細)

  rdp-cookie

  rdp-cookie(name):


3.2 bind


bind [<address>]:<port_range> [, ...]

bind [<address>]:<port_range> [, ...] interface <interface>


此指令僅能用於frontend和listen區段,用於定義一個或幾個監聽的套接字。


<address>:可選選項,其可以爲主機名、IPv4地址、IPv6地址或*;省略此選項、將其指定爲*或0.0.0.0時,將監聽當前系統的所有IPv4地址;

<port_range>:可以是一個特定的TCP端口,也可是一個端口範圍(如5005-5010),代理服務器將通過指定的端口來接收客戶端請求;需要注意的是,每組監聽的套接字<address:port>在同一個實例上只能使用一次,而且小於1024的端口需要有特定權限的用戶才能使用,這可能需要通過uid參數來定義;

<interface>:指定物理接口的名稱,僅能在Linux系統上使用;其不能使用接口別名,而僅能使用物理接口名稱,而且只有管理有權限指定綁定的物理接口;


3.3 mode


mode { tcp|http|health }


設定實例的運行模式或協議。默認爲tcp;當實現內容交換時,前端和後端必須工作於同一種模式(一般說來都是HTTP模式),否則將無法啓動實例。


tcp:實例運行於純TCP模式,在客戶端和服務器端之間將建立一個全雙工的連接,且不會對7層報文做任何類型的檢查;此爲默認模式,通常用於SSL、SSH、SMTP,mysql,HTTPS等應用;

http:實例運行於HTTP模式,客戶端請求在轉發至後端服務器之前將被深度分析,所有不與RFC格式兼容的請求都會被拒絕;

health:實例工作於health模式,其對入站請求僅響應“OK”信息並關閉連接,且不會記錄任何日誌信息;此模式將用於響應外部組件的健康狀態檢查請求;目前業講,此模式已經廢棄,因爲tcp或http模式中的monitor關鍵字可完成類似功能;


3.4 hash-type


hash-type <method>


定義用於將hash碼映射至後端服務器的方法;其不能用於frontend區段;可用方法有map-based和consistent,在大多數場景下推薦使用默認的map-based方法。


map-based:hash表是一個包含了所有在線服務器的靜態數組。其hash值將會非常平滑,會將權重考慮在列,但其爲靜態方法,對在線服務器的權重進行調整將不會生效,這意味着其不支持慢速啓動。此外,挑選服務器是根據其在數組中的位置進行的,因此,當一臺服務器宕機或添加了一臺新的服務器時,大多數連接將會被重新派發至一個與此前不同的服務器上,對於緩存服務器的工作場景來說,此方法不甚適用。

consistent:hash表是一個由各服務器填充而成的樹狀結構;基於hash鍵在hash樹中查找相應的服務器時,最近的服務器將被選中。此方法是動態的,支持在運行時修改服務器權重,因此兼容慢速啓動的特性。添加一個新的服務器時,僅會對一小部分請求產生影響,因此,尤其適用於後端服務器爲cache的場景。不過,此算法不甚平滑,派發至各服務器的請求未必能達到理想的均衡效果,因此,可能需要不時的調整服務器的權重以獲得更好的均衡性。


3.5 log


log global

log <address> <facility> [<level> [<minlevel>]]


爲每個實例啓用事件和流量日誌,因此可用於所有區段。每個實例最多可以指定兩個log參數,不過,如果使用了“log global”且"global"段已經定了兩個log參數時,多餘了log參數將被忽略。


global:當前實例的日誌系統參數同"global"段中的定義時,將使用此格式;每個實例僅能定義一次“log global”語句,且其沒有任何額外參數;

<address>:定義日誌發往的位置,其格式之一可以爲<IPv4_address:PORT>,其中的port爲UDP協議端口,默認爲514;格式之二爲Unix套接字文件路徑,但需要留心chroot應用及用戶的讀寫權限;

<facility>:可以爲syslog系統的標準facility之一;

<level>:定義日誌級別,即輸出信息過濾器,默認爲所有信息;指定級別時,所有等於或高於此級別的日誌信息將會被髮送;


3.6 maxconn


maxconn <conns>


設定一個前端的最大併發連接數,因此,其不能用於backend區段。對於大型站點來說,可以儘可能提高此值以便讓haproxy管理連接隊列,從而避免無法應答用戶請求。當然,此最大值不能超出“global”段中的定義。此外,需要留心的是,haproxy會爲每個連接維持兩個緩衝,每個緩衝的大小爲8KB,再加上其它的數據,每個連接將大約佔用17KB的RAM空間。這意味着經過適當優化後,有着1GB的可用RAM空間時將能維護40000-50000併發連接。


如果爲<conns>指定了一個過大值,極端場景下,其最終佔據的空間可能會超出當前主機的可用內存,這可能會帶來意想不到的結果;因此,將其設定了一個可接受值方爲明智決定。其默認爲2000。


3.7 default_backend


default_backend <backend>


用於frontend中,用於指明爲請求提供服務的backend;適用於default,listen,frontend。在沒有匹配的"use_backend"規則時爲實例指定使用的默認後端,因此,其不可應用於backend區段。在"frontend"和"backend"之間進行內容交換時,通常使用"use-backend"定義其匹配規則;而沒有被規則匹配到的請求將由此參數指定的後端接收。


use_backend <backend> [{if | unless} <condition>]:條件式後端指定;

   <condition>由ACL定義的;

只能應用在frontend,listen

<backend>:指定使用的後端的名稱;


使用案例:

(1)

use_backend     dynamic  if  url_dyn

use_backend     static   if  url_css url_img extension_img

default_backend dynamic


(2)

  acl url_static       path_beg       -i /static /p_w_picpaths /javascript /stylesheets

  acl url_static       path_end       -i .jpg .gif .png .css .js


 use_backend  static          if url_static

 default_backend             appsrvs

#---------------------------------------------------------------------

# static backend for serving up p_w_picpaths, stylesheets and such

#---------------------------------------------------------------------

#backend static

 #   balance     roundrobin

  #  server      static 127.0.0.1:4331 check


3.8 server


server <name> <address>[:port] [param*]


爲後端聲明一個server,因此,不能用於defaults和frontend區段。


<name>:出現在stats的頁面中,表示服務器的主機。爲此服務器指定的內部名稱,其將出現在日誌及警告信息中;如果設定了"http-send-server-name",它還將被添加至發往此服務器的請求首部中;

<address>:此服務器的的IPv4地址,也支持使用可解析的主機名,只不過在啓動時需要解析主機名至相應的IPv4地址;

[:port]:指定將連接請求所發往的此服務器時的目標端口,其爲可選項;未設定時,將使用客戶端請求時的同一相端口;

[param*]:爲此服務器設定的一系參數;其可用的參數非常多,具體請參考官方文檔中的說明,下面僅說明幾個常用的參數;


服務器或默認服務器參數:

backup:設定爲備用服務器,僅在負載均衡場景中的其它server均不可用於啓用此server;

check:默認使用tcp協議掃描對方端口;啓動對此server執行健康狀態檢查,其可以藉助於額外的其它參數完成更精細的設定,如:

  inter <delay>:設定健康狀態檢查的時間間隔,單位爲毫秒,默認爲2000;也可以使用fastinter和downinter來根據服務器端狀態優化此時間延遲;

  rise <count>:設定健康狀態檢查中,某離線的server從離線狀態轉換至正常狀態需要成功檢查的次數;

  fall <count>:確認server從正常狀態轉換爲不可用狀態需要檢查的次數;

cookie <value>:爲指定server設定cookie值,此處指定的值將在用戶請求入站時被檢查後發往相同值的服務器。第一次爲此值挑選的server將在後續的請求中被選中,其目的在於實現用戶持久連接的功能;

maxconn <maxconn>:指定此服務器接受的最大併發連接數;如果發往此服務器的連接數目高於此處指定的值,其將被放置於請求隊列,以等待其它連接被釋放;

maxqueue <maxqueue>:設定請求等待隊列的最大長度;0表示無上限;

observe <mode>:通過觀察服務器的通信狀況來判定其健康狀態,默認爲禁用,其支持的類型有“layer4”和“layer7”,“layer7”僅能用於http代理場景;

redir <prefix>:啓用重定向功能,將發往此服務器的GET和HEAD請求均以302狀態碼響應;需要注意的是,在prefix後面不能使用/,且不能使用相對地址,以免造成循環;例如:

  server srv1 172.16.100.6:80 redir http://p_w_picpathserver.magedu.com check

weight <weight>:權重,默認爲1,最大值爲256,0表示不參與負載均衡;


檢查方法:

option httpchk

option httpchk <uri>

option httpchk <method> <uri>

option httpchk <method> <uri> <version>:不能用於frontend段,例如:


backend https_relay

    mode tcp

    option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www.magedu.com

    server apache1 192.168.1.1:443 check port 80


3.11 stats enable


啓用基於程序編譯時默認設置的統計報告,不能用於“frontend”區段。只要沒有另外的其它設定,它們就會使用如下的配置:


  - stats uri   : /haproxy?stats

  - stats realm : "HAProxy Statistics"(認證提供的信息)

  - stats auth  : no authentication(不認證)

  - stats scope : no restriction(不限制)


儘管“stats enable”一條就能夠啓用統計報告,但還是建議設定其它所有的參數,以免其依賴於默認設定而帶來非期後果。下面是一個配置案例。


  backend public_www

    server websrv1 172.16.100.11:80

    stats enable

    stats hide-version

    stats scope   .

    stats uri     /haproxyadmin?stats

    stats realm   Haproxy\ Statistics

    stats auth    statsadmin:password

    stats auth    statsmaster:password


3.12 stats hide-version


stats hide-version


啓用統計報告並隱藏HAProxy版本報告,不能用於“frontend”區段。默認情況下,統計頁面會顯示一些有用信息,包括HAProxy的版本號,然而,向所有人公開HAProxy的精確版本號是非常有風險的,因爲它能幫助惡意用戶快速定位版本的缺陷和漏洞。儘管“stats hide-version”一條就能夠啓用統計報告,但還是建議設定其它所有的參數,以免其依賴於默認設定而帶來非期後果。具體請參照“stats enable”一節的說明。


3.13 stats realm


stats realm <realm>


啓用統計報告並高精認證領域,不能用於“frontend”區段。haproxy在讀取realm時會將其視作一個單詞,因此,中間的任何空白字符都必須使用反斜線進行轉義。此參數僅在與“stats auth”配置使用時有意義。


<realm>:實現HTTP基本認證時顯示在瀏覽器中的領域名稱,用於提示用戶輸入一個用戶名和密碼。


儘管“stats realm”一條就能夠啓用統計報告,但還是建議設定其它所有的參數,以免其依賴於默認設定而帶來非期後果。具體請參照“stats enable”一節的說明。


3.14 stats scope


stats scope { <name> | "." }


啓用統計報告並限定報告的區段,不能用於“frontend”區段。當指定此語句時,統計報告將僅顯示其列舉出區段的報告信息,所有其它區段的信息將被隱藏。如果需要顯示多個區段的統計報告,此語句可以定義多次。需要注意的是,區段名稱檢測僅僅是以字符串比較的方式進行,它不會真檢測指定的區段是否真正存在。


<name>:可以是一個“listen”、“frontend”或“backend”區段的名稱,而“.”則表示stats scope語句所定義的當前區段。


儘管“stats scope”一條就能夠啓用統計報告,但還是建議設定其它所有的參數,以免其依賴於默認設定而帶來非期後果。下面是一個配置案例。


backend private_monitoring

    stats enable

    stats uri     /haproxyadmin?stats

    stats refresh 10s


3.15 stats auth


stats auth <user>:<passwd>


啓用帶認證的統計報告功能並授權一個用戶帳號,其不能用於“frontend”區段。


<user>:授權進行訪問的用戶名;

<passwd>:此用戶的訪問密碼,明文格式;


此語句將基於默認設定啓用統計報告功能,並僅允許其定義的用戶訪問,其也可以定義多次以授權多個用戶帳號。可以結合“stats realm”參數在提示用戶認證時給出一個領域說明信息。在使用非法用戶訪問統計功能時,其將會響應一個“401 Forbidden”頁面。其認證方式爲HTTP Basic認證,密碼傳輸會以明文方式進行,因此,配置文件中也使用明文方式存儲以說明其非保密信息故此不能相同於其它關鍵性帳號的密碼。


儘管“stats auth”一條就能夠啓用統計報告,但還是建議設定其它所有的參數,以免其依賴於默認設定而帶來非期後果。


3.16 stats admin


stats admin { if | unless } <cond>


在指定的條件滿足時啓用統計報告頁面的管理級別功能,它允許通過web接口啓用或禁用服務器,不過,基於安全的角度考慮,統計報告頁面應該儘可能爲只讀的。此外,如果啓用了HAProxy的多進程模式,啓用此管理級別將有可能導致異常行爲。


目前來說,POST請求方法被限制於僅能使用緩衝區減去保留部分之外的空間,因此,服務器列表不能過長,否則,此請求將無法正常工作。因此,建議一次僅調整少數幾個服務器。下面是兩個案例,第一個限制了僅能在本機打開報告頁面時啓用管理級別功能,第二個定義了僅允許通過認證的用戶使用管理級別功能。


backend stats_localhost

    stats enable

    stats admin if LOCALHOST


backend stats_auth

    stats enable

    stats auth  haproxyadmin:password

    stats admin if TRUE


狀態:maint---維護下線

     ready---上線


示例:

健康檢查,添加參數

[root@node200 ~]# vim /etc/haproxy/haproxy.cfg

 80 backend appsrvs

 81     balance     roundrobin

 82     server  node2 192.168.112.130:80 check inter 2 rise 1 fall 3

 83     server  node3 192.168.112.140:80 check inter 2 rise 1 fall 3

 84 #    server  app3 127.0.0.1:5003 check

 85  #   server  app4 127.0.0.1:5004 check

[root@node200 ~]# !ser

service haproxy restart

停止 haproxy:                                             [確定]

正在啓動 haproxy:                                         [確定]


綁定端口

 63 frontend  main 

 64     bind *:80 65     bind *:8080 66   #  acl url_static       path_beg       -i /static /p_w_picpaths /javascript     /stylesheets

 67    # acl url_static       path_end       -i .jpg .gif .png .css .js

 68     

 69     #use_backend static          if url_static

 70     default_backend             appsrvs

[root@node200 ~]# !ser

service haproxy restart

停止 haproxy:                                             [確定]

正在啓動 haproxy:                                         [確定]

[root@node200 ~]# ss -tanl |grep 80

LISTEN     0      128                       *:8080                     *:*     

LISTEN     0      128                       *:80                       *:* 


狀態頁面

[root@node200 ~]# vim /etc/haproxy/haproxy.cfg

 81 backend appsrvs

 82     balance     roundrobin

 83     server  node2 192.168.112.130:80 check inter 2 rise 1 fall 3

 84     server  node3 192.168.112.140:80 check inter 2 rise 1 fall 3

 85 #    server  app3 127.0.0.1:5003 check

 86  #   server  app4 127.0.0.1:5004 check

 87 stats enable

[root@node200 ~]# !ser

service haproxy restart

停止 haproxy:                                             [確定]

正在啓動 haproxy:                                         [確定]

wKiom1ZUapDS9W7GAAXOiVptfLs579.jpg

 [root@node200 ~]# vim /etc/haproxy/haproxy.cfg

 81 backend appsrvs

 82     balance     roundrobin

 83     server  node2 192.168.112.130:80 check inter 2 rise 1 fall 3

 84     server  node3 192.168.112.140:80 check inter 2 rise 1 fall 3

 85 #    server  app3 127.0.0.1:5003 check

 86  #   server  app4 127.0.0.1:5004 check

 87 stats enable

 88 stats uri /haproxyadmin?stats

 89 stats auth admin:admin

 90 stats realm My\ Server

[root@node200 ~]# !ser

service haproxy restart

停止 haproxy:                                             [確定]

正在啓動 haproxy:                                         [確定]

wKiom1ZUbgqhfiZQAAH-z7P9Sdw871.jpg

wKiom1ZUb-SiZCzJAAUlcSi9pzU057.jpg

[root@node200 ~]# vim /etc/haproxy/haproxy.cfg

 87 stats enable

 88 stats uri /haproxyadmin?stats

 89 stats auth admin:admin

 90 stats realm My\ Server

 91 stats admin if TRUE

[root@node200 ~]# !ser

service haproxy restart

停止 haproxy:                                             [確定]

正在啓動 haproxy:                                         [確定]

wKioL1ZUcYagYGPRAATPIdMlvp4870.jpg

wKiom1ZUcYWwQSijAARpf6Ngtvs314.jpg


增加安全性

[root@node200 ~]# vim /etc/haproxy/haproxy.cfg

 81 backend appsrvs

 82     balance     roundrobin

 83     option httpchk

 84     server  node2 192.168.112.130:80 check inter 2 rise 1 fall 3

 85     server  node3 192.168.112.140:80 check inter 2 rise 1 fall 3

 86 #    server  app3 127.0.0.1:5003 check

 87  #   server  app4 127.0.0.1:5004 check

 88 listen stats_pages

 89 bind *:9001

 90 stats enable

 91 stats uri /haproxyadmin?stats

 92 stats auth admin:admin

 93 stats realm My\ Server

 94 stats admin if TRUE

[root@node200 ~]# !ser

service haproxy restart

停止 haproxy:                                             [確定]

正在啓動 haproxy:                                         [確定]

wKiom1ZUcz7giE8PAAGjotJeUHk457.jpg

wKioL1ZUc5_zmYXDAAbtIPZII_s070.jpg



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章