Haproxy的三种保持客户端会话保持方式

2017-03-25 15:41:41

 

haproxy 三种保持客户端Seesion;

1、源地址hash（用户IP识别）

haroxy 将用户IP通过hash计算后 指定到固定的真实服务器上（相似于nginx 的IP hash 指令）。

缺陷，当后端一台服务器挂了之后会形成部分session丢失。

配置指令

backend SOURCE_srv

  mode   http

  balance  source

  server app-node1  10.31.1.179:80  check port 80 inter 3000  rise 3  fall 3

  server app-node2  10.31.1.191:80  check port 80 inter 3000  rise 3  fall 3

  server app-node3   10.31.0.35:80  check port 80 inter 3000  rise 3  fall 3  

 

2、cookie 识别  

haproxy 将WEB服务端返回给客户端的cookie中插入haproxy中特定的字符串(或添加前缀)在后端的服务器COOKIE ID。

backend COOKIE_srv

   mode    http

   cookie SERVERID insert indirectnocache

   server app-node1 10.31.1.179:80 check  port 80 cookie  a  inter 3000  rise 3  fall 3

   server app-node2 10.31.1.191:80 check  port 80 cookie  b  inter 3000  rise 3  fall 3

   server app-node3 10.31.0.35:80  check  port 80 cookie  c inter 3000  rise 3  fall 3

 cookie参数说明：

  cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ] [ postonly ] [ preserve ] [ httponly ] [ secure ] [ domain <domain> ]* [ maxidle <idle> ] [ maxlife <life> ]

    [ rewrite | insert | prefix ]  /*三者互斥，只能选一*/
       rewrite  //表示cookie由服务器生成而且haproxy会在其值中注入该服务器的标识符;此关键字不能在HTTP隧道模式下工做。
       insert  //表示若是客户端没有cookie信息且有权限访问服务器时，持久性cookie必须经过haproxy穿插在服务器的响应报文中。当服务器收到相同名称的cookie而且没有“preserve（保存）”选项时，将会移除以前已存的cookie信息。所以，insert可视做"rewrite"的升级版。cookie信息仅仅做为会话cookie且不会存到客户端的磁盘上。默认除非加了“indirect(间接)”选项，不然服务器端会看到客户端端发送的cookie信息。因为缓存的影响，最好加上“nocache”或“postonly”选项。
       prefix  //表示不依赖专用的cookie作持久性，而是依赖现成的。用在某些特殊的场景，如客户端不支持一个以上的cookie和应用程序需求它。每当服务器创建一个名为<name>的cookie时，它将以服务器的标识符和分隔符为前缀。来自于客户端的请求报文中的前缀将会被删除以便服务器端能识别出它所发出的cookie，因为请求和响应报文都被修改过，因此此模式不能工做在隧道模式中。且不能和“indirect”共用，不然服务器端更新的cookie将不会被发到客户端.
   
   [ indirect ]    //指定此选项时，将不会向客户端发送服务器已经处理过请求的且可用的cookie信息。若是服务器设置这样一个cookie自己，它将被删除，除非“保存”选项也设置。在“插入”模式下，将从发送给服务器的请求中删除cookie，使持久机制从应用程序的角度彻底透明。
   [ nocache ]    //当客户端和haproxy间存在缓存时，使用此选项和insert搭配最好，以便确保若是一个cookie须要被插入时，可被缓存的响应会被标记成不可缓存。这很重要，举个例子：若是全部的持久cookie被添加到一个可缓存的主页上，以后全部的客户将从外部高速缓存读取页面并将共享相同的持久性cookie，会形成服务器阻塞。

 

在LB1上配置好HAProxy后，LB1将接受用户的全部请求。若是一个用户请求不包含任何cookie，那这个请求将被HAProxy转发到一台可用的WEB服务器。多是webA,webB，webC或webD。而后HAProxy将把处理这个请求的WEB服务器的cookie值插入到请求响应中。如SERVERID=A。当这个客户端再次访问并在HTTP请求头中带有SERVERID=A,HAProxy将会把它的请求直接转发给webA处理。在请求到达webA以前，cookie将被移除，webA将不会看到这个cookie。若是webA不可用，对应的请求将被转发到其余可用的WEB服务器，相应的cookie值也将被从新设置。

 

3、基于session

haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。

配置参数：appsession JSESSIONID len 64 timeout 5h request-learn

backend APPSESSION_srv

    mode    http

    appsession JSESSIONID len 64 timeout 5h request-learn

    server REALsrv_70       184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1

    server REALsrv_120      220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1

 

注意使用事项;

(1).若是客户端使用HTTP1.1(keep-alive)，只有第一个响应才会被插入cookie，而且HAProxy只会分析每一个session的第一个请求。在使用cookie的插入模式下，可能不会形成什么问题，由于HAProxy会当即在第一个响应中插入cookie，同一个session中的全部请求将被转发到同一台服务器上。可是，到达服务器端的请求中的cookie不会被删除，因此这要求后端服务器对来历不明的cookie不做敏感处理。若是不想引发其余的问题，可使用如下参数关掉keep-alive

 option httpclose

(2).因为一些缘由，一些客户端不能识别多个cookie，而且后端应用已经设置了cookie，若是HAProxy再对响应插入cookie后，这些客户端可能不能识别cookie。这种状况下，可使用cookie的prefix模式。

(3).LB1成为整个架构中的瓶颈，若是LB1不可用，那么客户端的全部请求都得不到响应。可使用Keepalived配置HAProxy解决LB1单点故障的问题。

(4).在以上配置中后端服务器是看不到客户端的真实IP地址的。可使用 forwardfor 参数，它可以在客户端的请求头中增长 X-Forwarded-For 字段。同时须要配置使用 httpclose 参数，确保每一个请求都被重写，而不仅是第一个请求被重写。

 option httpclose

 option forwardfor

 后端WEB服务器上的Nginx的日志格式须要增长$http_x_forwarded_for 变量;

 log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '

         '$status $body_bytes_sent "$http_referer" '

        '"$http_user_agent" "$http_x_forwarded_for"';

 

(5).在有些状况下，一些用户会将他们的浏览器的cookie功能关闭。这时候可能无法访问WEB服务器的内容。这种状况下，可使用HAProxy的 source 负载均衡算法替代  roundroubin算法。source 算法能够确保来自同一个IP的全部请求都到达同一台WEB服务器，可是前提是，可用的服务器的数量保持不变。

(6).不要在一个小型网络和代理服务器后面使用source 算法，由于请求分发会不太公平，可是在大型内部网络或互联网上使用source算法，转发效率很好。对于那些具备动态IP地址的客户端，只要它们可以接收cookie，那么请求转发就不会受到影响，由于HAProxy对cookie的处理具备较高优先级。

 

————————————————————————————————————————————

其他搭配方法：

backend NOSESSION_srv

   mode    http

   balance roundrobin

   server REALsrv_70     184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1

   server REALsrv_12    220.162.23.12:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1

 

backend ai_server

    mode    http

    balance roundrobin

    cookie  SERVERID

    server REALsrv_70 184.82.239.70:80 cookie 2 check inter 1500 rise 3 fall 3 weight 1

    server REALsrv_12 220.162.23.12:80 cookie 1 check inter 1500 rise 3 fall 3 weight 1

————————————————————————————————————————————

  cookie与session知识

Session：

Session是由应用服务器维持的一个服务器端的存储空间，用户在链接服务器时，会由服务器生成一个惟一的SessionID,用该SessionID 为标识符来存取服务器端的Session存储空间。
而SessionID这一数据则是保存到客户端，用Cookie保存的，用户提交页面时，会将这一 SessionID提交到服务器端，来存取Session数据。
服务器也经过URL重写的方式来传递SessionID的值，所以不是彻底依赖Cookie。若是客户端Cookie禁用，则服务器能够自动经过重写URL的方式来保存Session的值，而且这个过程对程序员透明。

 

Session--“会话控制”。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web 页时，若是该用户尚未会话，则 Web 服务器将自动建立一个 Session 对象。当会话过时或被放弃后，服务器将终止该会话。Session 对象最多见的一个用法就是存储用户的首选项。例如，若是用户指明不喜欢查看图形，就能够将该信息存储在 Session 对象中。有关使用 Session 对象的详细信息，请参阅“ASP 应用程序”部分的“管理会话”。注意 会话状态仅在支持 cookie 的浏览器中保留。

 

Cookie：

是在 HTTP 协议下，服务器或脚本能够维护客户工做站上信息的一种方式。Cookie 是由 Web 服务器保存在用户浏览器（客户端）上的小文本文件，它能够包含有关用户的信息。不管什么时候用户连接到服务器，Web 站点均可以访问 Cookie 信息。

目前有些Cookie 是临时的，有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的时间，一旦超过规定的时间，该 Cookie 就会被系统清除。

持续的Cookie 则保存在用户的 Cookie 文件中，下一次用户返回时，仍然能够对它进行调用。在 Cookie 文件中保存 Cookie，有些用户担忧 Cookie 中的用户信息被一些别有用心的人窃取，而形成必定的损害。其实，网站之外的用户没法跨过网站来得到 Cookie 信息。若是由于这种担忧而屏蔽 Cookie，确定会所以拒绝访问许多站点页面。由于，当今有许多 Web 站点开发人员使用 Cookie 技术，例如 Session 对象的使用就离不开 Cookie 的支持。