HaProxy 架构指南-Simple HTTP load-balancing with cookie insertion

1. 基于cookie插入的HTTP负载均衡

 192.168.1.1    192.168.1.11-192.168.1.14   192.168.1.2
-------+-----------+-----+-----+-----+--------+----    
       |           |     |     |     |       _|_db     
    +--+--+      +-+-+ +-+-+ +-+-+ +-+-+    (___)      
    | LB1 |      | A | | B | | C | | D |    (___)      
    +-----+      +---+ +---+ +---+ +---+    (___)      
    haproxy        4 cheap web servers


Config on haproxy (LB1) :
-------------------------

    listen webfarm 192.168.1.1:80
       mode http
       balance roundrobin
       cookie SERVERID insert indirect
       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


Description :
-------------
 - LB1 will receive clients requests.
 - if a request does not contain a cookie, it will be forwarded to a valid server
 - in return, a cookie "SERVERID" will be inserted in the response holding the server name (eg: "A").
 - when the client comes again with the cookie "SERVERID=A", LB1 will know that
   it must be forwarded to server A. The cookie will be removed so that the server does not see it.
 - if server "webA" dies, the requests will be sent to another valid server and a cookie will be reassigned.

                                                

Flows :
-------

(client) (haproxy) (server A)
  >-- GET /URI1 HTTP/1.0 ------------> |
               ( no cookie, haproxy forwards in load-balancing mode. )
                                       | >-- GET /URI1 HTTP/1.0 ---------->
                                       | <-- HTTP/1.0 200 OK -------------<
               ( the proxy now adds the server cookie in return )
  <-- HTTP/1.0 200 OK ---------------< |
      Set-Cookie: SERVERID=A |
  >-- GET /URI2 HTTP/1.0 ------------> |
      Cookie: SERVERID=A |
      ( the proxy sees the cookie. it forwards to server A and deletes it )
                                       | >-- GET /URI2 HTTP/1.0 ---------->
                                       | <-- HTTP/1.0 200 OK -------------<
   ( the proxy does not add the cookie in return because the client knows it )
  <-- HTTP/1.0 200 OK ---------------< |
  >-- GET /URI3 HTTP/1.0 ------------> |
      Cookie: SERVERID=A |
                                    ( ... )

HaProxy负载均衡选择后端SERVER，首次请求不含cookie，按照负载均衡算法选择后端SERVER。然后在给CLIENT的应答中插入含SERVER ID的cookie，
那么对于后续的请求，根据携带的SERVER ID cookie直接选择对应的SERVER进行转发。如果后端SERVER出现故障，则重新选择SERVER。

局限性：
1）当client使用keep-alive时，只有第1个的response会被插入cookie，同样只有第1个的request会被解析。当第1个请求到来后，立即选择SERVER，并
被插入第1个response中，后续的request由于在同一条session(四层)上，会被交给同一个后端的SERVER，看起来貌似没有什么问题。但是由于只解析第1
个request，因此后面的request会携带含SERVER ID的cookie到达后端SERVER，此时SERVER必须忽略无法识别的cookie字段，否则就出现了问题。另外
如果客户端使用PIPE LINE时，第一个response不一定是针对第1个request的，不过在当前的场景下暂时没有引入新的问题 <PIPE LINE没有普及，不清楚
HaProxy支持的如何>。

当含SERVER ID的cookie引发了后端SERVER处理故障时，我们需要将Keep-Alive关闭，使用的方法是 <文末会对该选项进行详细介绍>：

option httpclose

2）由于某些原因，客户端可能无法有效获取/使用response中的cookie信息，此时需要使用"prefix"模式 <见后文介绍>
3）HaProxy可能会挂掉，因此需要使用keepalived来做HaProxy的高可用性
4）有些应用需要Log原始客户端的IP地址，通过配置forwardfor选项，让HaProxy在请求头部中增加X-Forwarded-For字段，来记录原始的客户端IP地址。
此时必须使用httpclose选项来关闭Keepalive，保证HaProxy可以处理每一个请求头部。

option httpclose
option forwardfor

5）同样，有些应用需要Log客户端初始请求的目的地址，通过配置originalto选项，让HaProxy在请求头部增加X-Original-To字段，来记录原始目的IP地址。
此时必须使用httpclose选项来关闭Keepalive，保证HaProxy可以处理每一个请求头部。

option httpclose
option originalto

另外，互联网上可能存在一些客户端关闭了cookies功能，虽然可能导致很多问题。此时需要使用"source" balancing algorithm来替换"roundrobin"算法。
这种方式会导致同一个源IP发出的连接，分配到了同一台服务器上，显然可能不太公平，尤其时存在SNAT的场景。