Apache模块 mod_proxy_balancer · Apache 2.2 中文官方文档

# Apache模块 mod_proxy_balancer | [说明](#calibre_link-11) | `mod_proxy`的扩展，提供负载平衡支持 | | --- | --- | | [状态](#calibre_link-12) | 扩展(E) | | [模块名](#calibre_link-13) | proxy_balancer_module | | [源文件](#calibre_link-14) | proxy_balancer.c | | [兼容性](#calibre_link-58) | 仅在 Apache 2.1 及以后的版本中可用 | ### 概述 This module _requires_ the service of `mod_proxy`. It provides load balancing support for `HTTP`, `FTP`和`AJP13` protocols Thus, in order to get the ability of load balancing, `mod_proxy`和`mod_proxy_balancer` have to be present in the server. ### 警告在您没有[对您的服务器采取安全措施](#calibre_link-290)之前，不要启用代理。开放的代理服务器对你自己的内部网络和大规模的Internet网都是有安全隐患的。 ## Load balancer scheduler algorithm At present, there are 2 load balancer scheduler algorithms available for use: Request Counting and Weighted Traffic Counting. These are controlled via the `lbmethod` value of the Balancer definition. See the `Proxy` directive for more information. ## Request Counting Algorithm Enabled via `lbmethod=byrequests`, the idea behind this scheduler is that we distribute the requests among the various workers to ensure that each gets their configured share of the number of requests. It works as follows: <dfn class="calibre27">lbfactor</dfn> is _how much we expect this worker to work_, or _the workers's work quota_. This is a normalized value representing their "share" of the amount of work to be done. <dfn class="calibre27">lbstatus</dfn> is _how urgent this worker has to work to fulfill its quota of work_. <dfn class="calibre27">worker</dfn> is a member of the load balancer, usually a remote host serving one of the supported protocols. We distribute each worker's work quota to the worker, and then look which of them needs to work most urgently (biggest lbstatus). This worker is then selected for work, and its lbstatus reduced by the total work quota we distributed to all workers. Thus the sum of all lbstatus does not change(*) and we distribute the requests as desired. If some workers are disabled, the others will still be scheduled correctly. ``` for each worker in workers worker lbstatus += worker lbfactor total factor += worker lbfactor if worker lbstatus > candidate lbstatus candidate = worker candidate lbstatus -= total factor ``` If a balancer is configured as follows: | worker | a | b | c | d | | --- | --- | --- | --- | --- | | lbfactor | 25 | 25 | 25 | 25 | | --- | --- | --- | --- | --- | | lbstatus | 0 | 0 | 0 | 0 | | --- | --- | --- And b gets disabled, the following schedule is produced: | worker | a | b | c | d | | --- | --- | --- | --- | --- | | lbstatus | _-50_ | 0 | 25 | 25 | | --- | --- | --- | --- | --- | | lbstatus | -25 | 0 | _-25_ | 50 | | --- | --- | --- | --- | --- | | lbstatus | 0 | 0 | 0 | _0_ | | --- | --- | --- | --- | --- | | (repeat) | That is it schedules: a c d a c d a c d ... Please note that: | worker | a | b | c | d | | --- | --- | --- | --- | --- | | lbfactor | 25 | 25 | 25 | 25 | | --- | --- | --- Has the exact same behavior as: | worker | a | b | c | d | | --- | --- | --- | --- | --- | | lbfactor | 1 | 1 | 1 | 1 | | --- | --- | --- This is because all values of <dfn class="calibre27">lbfactor</dfn> are normalized with respect to the others. For: | worker | a | b | c | | --- | --- | --- | --- | | lbfactor | 1 | 4 | 1 | | --- | --- worker b will, on average, get 4 times the requests that a和c will. The following asymmetric configuration works as one would expect: | worker | a | b | | --- | --- | --- | | lbfactor | 70 | 30 | | --- | --- | --- | | lbstatus | _-30_ | 30 | | --- | --- | --- | | lbstatus | 40 | _-40_ | | --- | --- | --- | | lbstatus | _10_ | -10 | | --- | --- | --- | | lbstatus | _-20_ | 20 | | --- | --- | --- | | lbstatus | _-50_ | 50 | | --- | --- | --- | | lbstatus | 20 | _-20_ | | --- | --- | --- | | lbstatus | _-10_ | 10 | | --- | --- | --- | | lbstatus | _-40_ | 40 | | --- | --- | --- | | lbstatus | 30 | _-30_ | | --- | --- | --- | | lbstatus | _0_ | 0 | | --- | --- | --- | | (repeat) | That is after 10 schedules, the schedule repeats and 7 a are selected with 3 b interspersed. ## Weighted Traffic Counting Algorithm Enabled via `lbmethod=bytraffic`, the idea behind this scheduler is very similar to the Request Counting method, with the following changes: <dfn class="calibre27">lbfactor</dfn> is _how much traffic, in bytes, we want this worker to handle_. This is also a normalized value representing their "share" of the amount of work to be done, but instead of simply counting the number of requests, we take into account the amount of traffic this worker has seen. If a balancer is configured as follows: | worker | a | b | c | | --- | --- | --- | --- | | lbfactor | 1 | 2 | 1 | | --- | --- Then we mean that we want b to process twice the amount of bytes than a或c should. It does not necessarily mean that b would handle twice as many requests, but it would process twice the I/O. Thus, the size of the request and response are applied to the weighting and selection algorithm. ## Enabling Balancer Manager Support This module _requires_ the service of `mod_status`. Balancer manager enables dynamic update of balancer members. You can use balancer manager to change the balance factor or a particular member, or put it in the off line mode. Thus, in order to get the ability of load balancer management, `mod_status`和`mod_proxy_balancer` have to be present in the server. To enable load balancer management for browsers from the foo.com domain add this code to your `httpd.conf` configuration file ``` <Location /balancer-manager> SetHandler balancer-manager Order Deny,Allow Deny from all Allow from .foo.com </Location> ``` You can now access load balancer manager by using a Web browser to access the page `http://your.server.name/balancer-manager`