解决 HTTP 请求被 LVS reset 的问题

最近两天遇到了 HTTP 请求被 LVS reset 的问题,LVS 默认有三个超时参数,如下:

# ipvsadm -L –timeout
Timeout (tcp tcpfin udp): 90 3 300

第一个就是 TCP 的空闲连接时间,这里超过 90 s 连接没数据会被 LVS reset 掉,在 HTTP Client 端可以看到 Connection reset by peer。我的某个服务 HTTP 请求时间很长,至少有 5 min,所以每次都会被 reset。

 

一开始我想到的解决办法是在 HTTP Client (HTTP 请求使用 requests)指定 so_keepidle参数小于 90 s。

因为 requests 使用 urllib3,而 urllib3 使用标准库 http.client(Python 3),Python 2.x 版本使用 httplib(它们会调用 socket.create_connection),所以我们可以封装一下来实现修改 so_keepidle:

import httplib
orig_connect = httplib.HTTPConnection.connect
def monkey_connect(self):
    orig_connect(self)
    self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
    self.sock.setsockopt(socket.SOL_TCP, socket.TCP_KEEPIDLE, 10)
    # sock.setsockopt(socket.SOL_TCP, socket.TCP_KEEPINTVL, 10)
    # sock.setsockopt(socket.SOL_TCP, socket.TCP_KEEPCNT, 100)
httplib.HTTPConnection.connect = monkey_connect
import requests

但是抓包发现 HTTP Client 端根本不发送 TCP keepalive 的包来保活,很是奇怪(可能是这段代码有问题,引用的还是老的模块,没继续debug,mark)。

 

后来发现可以在 Nginx 来实现 so_keepidle(LVS 后面是 Nginx),而且 Nginx 支持 so_keepidle 的配置,在 linsten 后面指定,格式如下:

222111h4s4ipokimf3zppr

比如:listen 80 so_keepalive=60::;

实测有效,终于解决了因为 HTTP 请求时间太长被 LVS reset 的问题,而且对域名生效,不影响其他域名(如果修改 LVS TCP idle timeout,对所有域名都有影响)。

 

参考:

http://stackoverflow.com/questions/15148225/is-it-possible-to-override-the-default-socket-options-in-requests

https://linux.cn/article-3766-1.html

http://nginx.org/en/docs/http/ngx_http_core_module.html

 

长连接下LVS和NGINX对HTTP请求的处理是否使用负载均衡

今天突然想对长连接下LVS和NGINX是怎么做负载均衡的,会不会转发到同一个后端机器,so 测试一下。

Client —> LVS —> NGINX —> APP

测试点

在持久连接(长连接)的情况下,http的请求会保持一条路径么(同一个LVS、NGINX、APP)?

准备,分别对 NGINX 和 LVS 测试,测试路径如下:

1. NGINX —> APP

2. LVS —> APP

测试一

测试代码(http1.1默认支持keepalive,不用指定即是长连接)

[python]#!/usr/bin/python
#-*- coding: utf-8 -*-

import urllib
import httplib
import time

def keepalive(t):
url = "60.28.208.8"

conn = httplib.HTTPConnection(url)

conn.request("GET", "/test")
ret = conn.getresponse()
print ret.status, ret.reason
data = ret.read()

time.sleep(10)

conn.request("GET", "/test")
ret = conn.getresponse()
print ret.status, ret.reason
data = ret.read()

conn.close()
[/python]

NGINX 配置文件

upstream test-nodes {
    server pxe0.hy01:8888;
    server pxe2.hy01:8888;
}

server {
    listen 80;
    server_name 60.28.208.8;
    access_log /home/work/nginx/logs/test_wandoujia.access.log main;
    error_log /home/work/nginx/logs/test_wandoujia.error.log;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://test-nodes;
    }
}

其中,NGINX的 keepalive_timeout 设置为30,保证 在我们sleep 的时间内 连接不断。

跑脚本发现,第一次http请求落在 test0 上,第二次落在 test1 上,说明在 http持久连接下 NGINX 依然会 选择不同的后端进行 负载均衡。

测试二

1. persistence_timeout 设置为0,syn_proxy 关闭的情况下,两次请求 落到同一个后端。

2. persistence_timeout 设置为0,syn_proxy 打开的情况下,两次请求 落到同一个后端。

3. persistence_timeout 设置不为0,syn_proxy 关闭的情况下,两次请求 落到同一个后端。

4. persistence_timeout 设置不为0,syn_proxy 打开的情况下,两次请求 落到同一个后端。

看起来和 syn_proxy 没关系,可以忽略syn_proxy 了。

可以看出,在http持久连接下,LVS 会把 请求转给同一个后端。

另外,我也验证了,如果是多个单独的HTTP请求(请求完就关闭连接),LVS 会负载均衡到 两个后端。

总结

持久连接下,LVS会把请求转发到同一个后端,而NGINX 会转发到不同的后端。

那么即使在长连接下,NGINX也会对请求做负载均衡,这种情况会造成SESSION失效,所以对和账号相关的服务,需要做会话保持,还好 像LVS、NGINX 和HAPROXY 这些负载均衡器都有保持会话的方法。

LVS fullnat模式下 syn_proxy机制对 建立连接过程 和 TCP option 的影响

我们的前端负载均衡已经切换到了LVS FULLNAT模式,它比LVS DR 模式 的好处是 LVS和后端机器不用在一个二层网络里面,非常好扩展,不好的地方是后端机器要装一台TOA模块来识别 HTTP请求的源IP。

想了解LVS FULLNAT的话可以参考这个链接:

http://kb.linuxvirtualserver.org/wiki/IPVS_FULLNAT_and_SYNPROXY

用LVS fullnat的时候其实需要注意一些TCP option的设置,比如 timestamps 和 windows scaling,而且 TCP option 和 synproxy 还有关系,在这篇文章我们手动测试,得出 怎么在LVS fullnat机器上 设置TCP option 。

 

环境:

LVS VIP :  60.28.208.10
LVS fullnat localip 段:10.0.19.0/24
后端IP :  10.0.11.12

 

探测的抓包

LVS 检测后端时LVS的抓包记录:

18:45:36.023248 IP 10.0.19.226.63923 > 10.0.11.12.http: Flags [S], seq 1537556744, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 18:45:36.023270 IP 10.0.19.226.19042 > 10.0.11.12.https: Flags [S], seq 520304659, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 18:45:36.023544 IP 10.0.11.12.http > 10.0.19.226.63923: Flags [S.], seq 3628316982, ack 1537556745, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 18:45:36.023560 IP 10.0.19.226.63923 > 10.0.11.12.http: Flags [.], ack 1, win 115, length 0 18:45:36.023565 IP 10.0.11.12.https > 10.0.19.226.19042: Flags [S.], seq 458068257, ack 520304660, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 18:45:36.023572 IP 10.0.19.226.19042 > 10.0.11.12.https: Flags [.], ack 1, win 115, length 0 18:45:36.023589 IP 10.0.19.226.63923 > 10.0.11.12.http: Flags [R.], seq 1, ack 1, win 115, length 0 18:45:36.023602 IP 10.0.19.226.19042 > 10.0.11.12.https: Flags [R.], seq 1, ack 1, win 115, length 0

LVS 检测后端时后端的抓包记录:

18:46:26.041901 IP 10.0.19.226.61028 > 10.0.11.12.http: Flags [S], seq 3032456781, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

18:46:26.041937 IP 10.0.11.12.http > 10.0.19.226.61028: Flags [S.], seq 1104080475, ack 3032456782, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
18:46:26.041951 IP 10.0.19.226.40349 > 10.0.11.12.https: Flags [S], seq 849356025, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
18:46:26.041960 IP 10.0.11.12.https > 10.0.19.226.40349: Flags [S.], seq 1050279505, ack 849356026, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
18:46:26.042113 IP 10.0.19.226.61028 > 10.0.11.12.http: Flags [.], ack 1, win 115, length 0
18:46:26.042147 IP 10.0.19.226.40349 > 10.0.11.12.https: Flags [.], ack 1, win 115, length 0
18:46:26.042310 IP 10.0.19.226.61028 > 10.0.11.12.http: Flags [R.], seq 1, ack 1, win 115, length 0
18:46:26.042373 IP 10.0.19.226.40349 > 10.0.11.12.https: Flags [R.], seq 1, ack 1, win 115, length 0

上面可以看到,LVS 从localip 段里面选一个IP,起两个端口分别探测 80 和 443,建立连接之后 里面发送 RST 给后端,这样探测也成功了。

 

请求的抓包

在一台机器上执行下面命令:
curl -H “Host:10.0.11.12” http://60.28.208.10/test

LVS 上面抓VIP 的包如下:
tcpdump -n -i em1 host 60.28.208.10 and port 80
17:08:00.122008 IP 111.206.15.146.15405 > 60.28.208.10.http: Flags [S], seq 1679917190, win 14600, options [mss 1460,sackOK,TS val 1412716450 ecr 0,nop,wscale 7], length 0
17:08:00.122018 IP 60.28.208.10.http > 111.206.15.146.15405: Flags [S.], seq 2689133917, ack 1679917191, win 14600, options [mss 1452,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 1], length 0
17:08:00.132352 IP 111.206.15.146.15405 > 60.28.208.10.http: Flags [.], ack 1, win 115, length 0
17:08:00.132439 IP 111.206.15.146.15405 > 60.28.208.10.http: Flags [P.], seq 1:169, ack 1, win 115, length 168
17:08:00.132877 IP 60.28.208.10.http > 111.206.15.146.15405: Flags [.], ack 169, win 123, length 0
17:08:01.138207 IP 60.28.208.10.http > 111.206.15.146.15405: Flags [P.], seq 1:215, ack 169, win 123, length 214
17:08:01.148585 IP 111.206.15.146.15405 > 60.28.208.10.http: Flags [.], ack 215, win 123, length 0
17:08:01.148741 IP 111.206.15.146.15405 > 60.28.208.10.http: Flags [F.], seq 169, ack 215, win 123, length 0
17:08:01.149060 IP 60.28.208.10.http > 111.206.15.146.15405: Flags [F.], seq 215, ack 170, win 123, length 0
17:08:01.159344 IP 111.206.15.146.15405 > 60.28.208.10.http: Flags [.], ack 216, win 123, length 0

LVS 上面抓连接后端机器的包:
tcpdump -n -i em2 net 10.0.19.0/24 and host 10.0.11.12
17:08:00.132468 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [S], seq 3159822860, win 5000, options [Unknown Option 2003c2d6fce0f92,mss 1440,nop,nop,sackOK,nop,wscale 7], length 0
17:08:00.132656 IP 10.0.11.12.http > 10.0.19.227.commplex-link: Flags [S.], seq 2205177579, ack 3159822861, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
17:08:00.132686 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [P.], seq 1:169, ack 1, win 115, options [Unknown Option 2003c2d6fce0f92], length 168
17:08:00.132855 IP 10.0.11.12.http > 10.0.19.227.commplex-link: Flags [.], ack 169, win 123, length 0
17:08:01.138194 IP 10.0.11.12.http > 10.0.19.227.commplex-link: Flags [P.], seq 1:215, ack 169, win 123, length 214
17:08:01.148598 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [.], ack 215, win 123, length 0
17:08:01.148749 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [F.], seq 169, ack 215, win 123, length 0
17:08:01.149046 IP 10.0.11.12.http > 10.0.19.227.commplex-link: Flags [F.], seq 215, ack 170, win 123, length 0
17:08:01.159357 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [.], ack 216, win 123, length 0

上面的包是在开启syn_proxy的时候抓的,可以看出(注意看时间点),Client 请求来的时候,LVS 会先和Client 建好连接,然后在 Client 请求数据的时候 LVS 选择一个localip端口 和 后端 建立连接,建立成功后LVS 直接 向后端请求数据,获取数据后 再通过 VIP 传给 Client。

 

下面我们把 syn_proxy 关掉之后重新抓一下看看。

tcpdump -n -i em1 host 60.28.208.10 and port 80
17:10:54.142439 IP 111.206.15.146.15408 > 60.28.208.10.http: Flags [S], seq 50780707, win 14600, options [mss 1460,sackOK,TS val 1412890473 ecr 0,nop,wscale 7], length 0
17:10:54.142802 IP 60.28.208.10.http > 111.206.15.146.15408: Flags [S.], seq 629114004, ack 50780708, win 14600, options [mss 1452,nop,nop,sackOK,nop,wscale 7], length 0
17:10:54.153112 IP 111.206.15.146.15408 > 60.28.208.10.http: Flags [.], ack 1, win 115, length 0
17:10:54.153180 IP 111.206.15.146.15408 > 60.28.208.10.http: Flags [P.], seq 1:169, ack 1, win 115, length 168
17:10:54.153360 IP 60.28.208.10.http > 111.206.15.146.15408: Flags [.], ack 169, win 123, length 0
17:10:55.158651 IP 60.28.208.10.http > 111.206.15.146.15408: Flags [P.], seq 1:215, ack 169, win 123, length 214
17:10:55.168912 IP 111.206.15.146.15408 > 60.28.208.10.http: Flags [.], ack 215, win 123, length 0
17:10:55.168940 IP 111.206.15.146.15408 > 60.28.208.10.http: Flags [F.], seq 169, ack 215, win 123, length 0
17:10:55.169284 IP 60.28.208.10.http > 111.206.15.146.15408: Flags [F.], seq 215, ack 170, win 123, length 0
17:10:55.179620 IP 111.206.15.146.15408 > 60.28.208.10.http: Flags [.], ack 216, win 123, length 0

tcpdump -n -i em2 net 10.0.19.0/24 and host 10.0.11.12
17:10:54.142475 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [S], seq 1583761902, win 14600, options [Unknown Option 2003c306fce0f92,mss 1460,sackOK,TS val 1412890473 ecr 0,nop,wscale 7], length 0
17:10:54.142766 IP 10.0.11.12.http > 10.0.19.227.commplex-link: Flags [S.], seq 629114004, ack 1583761903, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
17:10:54.153128 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [.], ack 1, win 115, options [Unknown Option 2003c306fce0f92], length 0
17:10:54.153192 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [P.], seq 1:169, ack 1, win 115, options [Unknown Option 2003c306fce0f92], length 168
17:10:54.153348 IP 10.0.11.12.http > 10.0.19.227.commplex-link: Flags [.], ack 169, win 123, length 0
17:10:55.158639 IP 10.0.11.12.http > 10.0.19.227.commplex-link: Flags [P.], seq 1:215, ack 169, win 123, length 214
17:10:55.168925 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [.], ack 215, win 123, length 0
17:10:55.168944 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [F.], seq 169, ack 215, win 123, length 0
17:10:55.169272 IP 10.0.11.12.http > 10.0.19.227.commplex-link: Flags [F.], seq 215, ack 170, win 123, length 0
17:10:55.179630 IP 10.0.19.227.commplex-link > 10.0.11.12.http: Flags [.], ack 216, win 123, length 0

通过上面的抓包可以看到(同样看时间点),关闭syn_proxy 的时候,LVS 接受到请求,此时开启一个localip的一个端口 给后端发送 SYN,收到 后端的SYN+ACK之后,LVS通过VIP 给Client 返回 SYN+ACK,然后 Client 会再发送 ACK,VIP 会接收到这个ACK,然后再通过localip 传给 后端,后端收到后 建立连接。看这个流程,LVS 纯粹扮演 Proxy 的角色。

syn_proxy 机制会影响 Client 到 Server 的TCP 连接的Option 选项,下面细看。

 

关于timestamps 的测试

Client —> LVS —> Server

LVS 上面有三个和 timestamps 相关的参数 :
net.ipv4.tcp_timestamps
net.ipv4.vs.fullnat_timestamp_remove_entry
net.ipv4.vs.synproxy_timestamp

(LVS 默认 net.ipv4.vs.fullnat_timestamp_remove_entry = 1 ,net.ipv4.vs.synproxy_timestamp = 0)

在开启 syn_proxy 情况下的测试:

1. 即使 Client 和 Server 的 timestamps 都设置为1 ,只要 LVS net.ipv4.vs.synproxy_timestamp 不设置为1 ,timestamps 就不会启用。此时  LVS 的 net.ipv4.tcp_timestamps 和 net.ipv4.vs.fullnat_timestamp_remove_entry 完全没用。

2. 如果Client 关闭了 net.ipv4.tcp_timestamps ,timestamps 选项不会启用。

3. 比较诧异的是,无论 Server 的 net.ipv4.tcp_timestamps 是否设置为1,只要LVS 开启 net.ipv4.vs.synproxy_timestamp 和 Client 开启 net.ipv4.tcp_timestamps,建立的TCP连接 就会启用 timestamps (此时在Server 上抓包 会看到 TS val 和 ecr )

在关闭 syn_proxy 情况下的测试:

1. 此时 net.ipv4.vs.fullnat_timestamp_remove_entry  参数起作用,即使 Client 和 Server 的 timestamps 都设置为1 ,只要 LVS net.ipv4.vs.fullnat_timestamp_remove_entry 不设置为0 ,timestamps 就不会启用。

2. 如果Client 关闭了 net.ipv4.tcp_timestamps ,timestamps 选项不会启用。

3. 如果Server关闭了 net.ipv4.tcp_timestamps ,timestamps 选项不会启用。

总结:

1. syn_proxy 开启,net.ipv4.vs.synproxy_timestamp 决定LVS 是否启用timestamps。

2. syn_proxy 关闭,net.ipv4.vs.fullnat_timestamp_remove_entry 决定LVS 是否启用timestamps。

3. LVS FULLNAT 模式 的 net.ipv4.tcp_timestamps 参数 完全没用,设置与不设置都不会影响timestamps

4. 简单点,如果想开启LVS的 timestamps,把 net.ipv4.vs.synproxy_timestamp 设置成1,同时把  net.ipv4.vs.fullnat_timestamp_remove_entry 设置成 0

 

关于windows  scaling 的测试

Client —> LVS —> Server

在开启 syn_proxy 情况下的测试:

1. net.ipv4.vs.synproxy_wscale 决定连接 是否 wscale,即使 Client 和 Server 都开启了wscale,只要LVS 不开启 net.ipv4.vs.synproxy_wscale,连接就不会开启wscale。

2. 如果Client 不开启 net.ipv4.tcp_window_scaling ,连接就不会开启 wscale。

3. Server 的 net.ipv4.tcp_window_scaling 变的没用,即使没打开,只要 Client 打开了net.ipv4.tcp_window_scaling 而且LVS 打开了 net.ipv4.vs.synproxy_wscale ,连接就会打开 wscale

在关闭 syn_proxy 情况下的测试:

1. 只要 Client 和 Server 同时开启 wscale ,连接就会开启 wscale,不管 LVS 如何设置。

总结:

1. LVS 的 net.ipv4.tcp_window_scaling 完全没用,可忽略这个参数。

2. 想开启LVS 的wscale, 把 net.ipv4.vs.synproxy_wscale  设置成1