分类： LINUX
2011-05-31 11:05:35
现在你可以不用添加更多的cookie，而是使用已有的cookie。如果应用已经生成J足够跟踪session的SESSIONID cookie，我们会在看到该cookie时，在它前面加上server name前缀。由于load-balancer变得关键，因此，可以通过利用keepalived使得运行在VRRP模式下的第二台热备它。
从网站上下载最新版本的keepalived，并且安装在load-balancer LB1和LB2上。
在两个load-balancer(我们仍然使用原始IP)之间，我们使用一个共享IP。在任何时刻只有1个load-balancers处于活跃状态。为了允许proxy在Linux2.4下绑定一个共享IP，需要在/proc中启用如下配置：
# echo 1 >/proc/sys/net/ipv4/ip_nonlocal_bind
proxies上的配置(LB1 and LB2):
listen webfarm 192.168.1.1:80
mode http
balance roundrobin
cookie JSESSIONID prefix
option httpclose
option forwardfor
option httpchk HEAD /index.html HTTP/1.0
server webA 192.168.1.11:80 cookie A check
server webB 192.168.1.12:80 cookie B check
server webC 192.168.1.13:80 cookie C check
server webD 192.168.1.14:80 cookie D check
提示：proxy会修改client和server发出的每个cookie，因此proxy能够访问每个session中的所有request的所有cookie是非常重要的。这意味着不是keepalive(HTTP/1.1)，需要使用'httpclose'选项。只有你能确认clients不会使用keepalive，才能删除这个选项。
LB1和LB2上keepalived的配置：
vrrp_script chk_haproxy { # Requires keepalived-1.1.13
script "killall -0 haproxy" # cheaper than pidof
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}
vrrp_instance VI_1 {
interface eth0
state MASTER
virtual_router_id 51
priority 101 # 101 on master, 100 on backup
virtual_ipaddress {
192.168.1.1
}
track_script {
chk_haproxy
}
}
描述：
—LB1是VRRP的主（keepalived），LB2是备。他们都监控haproxy进程，并且如果haproxy failed则降低他们的权重，迁移至另外的节点；
—LB1将在IP：192.168.1.1上接收client request
—两个LB用他们的内部IP发送健康检测
—如果request不包含cookie，request会被前传至1个有效的server
—在回复时，如果看到JESSIONID cookie，proxy会在cookie加上以('~')为分隔符的server name前缀；
—如果client再次访问时带着"JSESSIONID=A~xxx" cookie，LB1会知道这个request必须前传至 server A。在把cookie发送给server之前，cookie中的server name会先被剔除出来。
—如果server "webA"宕机，requests会被前传到另外的有效服务器，并且会重新分配cookie；
数据流：
(client) (haproxy) (server A)
>-- GET /URI1 HTTP/1.0 ------------> |
( no cookie, haproxy forwards in load-balancing mode. )
| >-- GET /URI1 HTTP/1.0 ---------->
| X-Forwarded-For: 10.1.2.3
| <-- HTTP/1.0 200 OK -------------<
( no cookie, nothing changed )
<-- HTTP/1.0 200 OK ---------------< |
>-- GET /URI2 HTTP/1.0 ------------> |
( no cookie, haproxy forwards in lb mode, possibly to another server. )
| >-- GET /URI2 HTTP/1.0 ---------->
| X-Forwarded-For: 10.1.2.3
| <-- HTTP/1.0 200 OK -------------<
| Set-Cookie: JSESSIONID=123
( the cookie is identified, it will be prefixed with the server name )
<-- HTTP/1.0 200 OK ---------------< |
Set-Cookie: JSESSIONID=A~123 |
>-- GET /URI3 HTTP/1.0 ------------> |
Cookie: JSESSIONID=A~123 |
( the proxy sees the cookie, removes the server name and forwards
to server A which sees the same cookie as it previously sent )
| >-- GET /URI3 HTTP/1.0 ---------->
| Cookie: JSESSIONID=123
| X-Forwarded-For: 10.1.2.3
| <-- HTTP/1.0 200 OK -------------<
( no cookie, nothing changed )
<-- HTTP/1.0 200 OK ---------------< |
( ... )
提示：
有时，在一个集群中有一些性能强劲的server，也有一些性能差一些的server。在这种情况下，很有必要告诉haproxy这些server在性能上的差异。假设WebA和WebB是两台老的P3-1.2 GHz，WebC和WebD是最新的Opteron-2.6 GHz。如果你的application关注CPU，则你可以假设这两台服务器之间的性能比为2.6/1.2。你可以通过使用1-256之间数值标记的"weight"关键字，告诉haproxy这些性能差异。它可以用这些比例来平滑load：
server webA 192.168.1.11:80 cookie A weight 12 check
server webB 192.168.1.12:80 cookie B weight 12 check
server webC 192.168.1.13:80 cookie C weight 26 check
server webD 192.168.1.14:80 cookie D weight 26 check
2.1 包含外部L4 load-balancers的变化
作为基于VRRP主备方案的替代方案，他们也可以使用L4 load-balancer（如：Alteon）进行负载，这些L4 load-balancer也可以检查这些运行在proxy上的服务：
| VIP=192.168.1.1
+----+----+
| Alteon |
+----+----+
|
192.168.1.3 | 192.168.1.4 192.168.1.11-192.168.1.14 192.168.1.2
-------+-----+------+-----------+-----+-----+-----+--------+----
| | | | | | _|_db
+--+--+ +--+--+ +-+-+ +-+-+ +-+-+ +-+-+ (___)
| LB1 | | LB2 | | A | | B | | C | | D | (___)
+-----+ +-----+ +---+ +---+ +---+ +---+ (___)
haproxy haproxy 4 cheap web servers
proxy(LB1和LB2)上的配置：
listen webfarm 0.0.0.0:80
mode http
balance roundrobin
cookie JSESSIONID prefix
option httpclose
option forwardfor
option httplog
option dontlognull
option httpchk HEAD /index.html HTTP/1.0
server webA 192.168.1.11:80 cookie A check
server webB 192.168.1.12:80 cookie B check
server webC 192.168.1.13:80 cookie C check
server webD 192.168.1.14:80 cookie D check
"dontlognull"选项用来防止记录Alteon发出的健康检测。如果一个session交互没有数据，这个session就不会被记录。
Alteon上的配置：
/c/slb/real 11
ena
name "LB1"
rip 192.168.1.3
/c/slb/real 12
ena
name "LB2"
rip 192.168.1.4
/c/slb/group 10
name "LB1-2"
metric roundrobin
health tcp
add 11
add 12
/c/slb/virt 10
ena
vip 192.168.1.1
/c/slb/virt 10/service http
group 10
提示：Alteon上的健康检测被设置为'tcp'，用来防止proxy把连接前传。Alteon也可以设置为'http'，但是这样proxy必须把配置Alteon的地址为"monitor-net"，那样Alteon可以真实的以http会话的方式检测proxy而不会把连接前传到后端的servers。检查下一节可以看到怎样使用monitor-net的例子。
2.2 通用的TCP中继和外部L4 load-balancers有时，能够中继通用的TCP协议(如：SMTP, TSE, VNC等)是非常有用的，如访问内部稀有网络。当你在使用外部 load-balancers需要发送周期行的健康检测至proxy时问题就会出现，这是因为健康检测会被前传至后端servers。对这个问题的1个解决方案是通过使用"monitor-net"用一个专用的网络来监控系统，并且必须不会前传连接和记录。
提示：这个特性只有在1.1.32或者1.2.6版本以上才支持。
| VIP=172.16.1.1 |
+----+----+ +----+----+
| Alteon1 | | Alteon2 |
+----+----+ +----+----+
192.168.1.252 | GW=192.168.1.254 | 192.168.1.253
| |
------+---+------------+--+-----------------> TSE farm : 192.168.1.10
192.168.1.1 | | 192.168.1.2
+--+--+ +--+--+
| LB1 | | LB2 |
+-----+ +-----+
haproxy haproxy
在LB1和LB2上的配置：
listen tse-proxy
bind :3389,:1494,:5900 # TSE, ICA and VNC at once.
mode tcp
balance roundrobin
server tse-farm 192.168.1.10
monitor-net 192.168.1.252/31
"monitor-net"选项指示haproxy对来自192.168.1.252和192.168.1.253的请求不记录、不前传并且马上关闭连接。Alteon load-balancers将可以检测到proxy是活跃的而不会扰动正常服务。
Alteon上的配置：
----------------------
/c/l3/if 1
ena
addr 192.168.1.252
mask 255.255.255.0
/c/slb/real 11
ena
name "LB1"
rip 192.168.1.1
/c/slb/real 12
ena
name "LB2"
rip 192.168.1.2
/c/slb/group 10
name "LB1-2"
metric roundrobin
health tcp
add 11
add 12
/c/slb/virt 10
ena
vip 172.16.1.1
/c/slb/virt 10/service 1494
group 10
/c/slb/virt 10/service 3389
group 10
/c/slb/virt 10/service 5900
group 10
SSL的特殊处理：
有时，即使在TCP模式下，你需要给远程系统发送健康检测以便能够在server发生故障时能够切换到备份服务器。当然，你可以简单地启用TCP健康检查，但是在proxy和远程server之间的firewalls会自己确认TCP连接，从而显示为1个始终活跃的server。由于这是在使用SSL的长途通信中普遍遇到的问题，一个SSL健康检查已实现来要解决这个问题。
它发出的SSL messages 消息到远程server，server回复Hello messages。可以很容易的进行配置：
listen tcp-syslog-proxy
bind :1514 # listen to TCP syslog traffic on this port (SSL)
mode tcp
balance roundrobin
option ssl-hello-chk
server syslog-prod-site 192.168.1.10 check
server syslog-back-site 192.168.2.10 check backup
