저는 현재 몇 개의 웹사이트에 대한 역방향 프록시 역할을 하도록 HAproxy 시스템을 설정하고 있습니다. 다른 컴퓨터가 물리적으로 연결되어 있지 않기 때문에 OpenVPN을 사용하여 컴퓨터 간에 VPN을 만듭니다.
기술적으로 모든 것이 작동하고 있습니다. 그러나 내 문제는 프록시를 통해 파이프하는 요청이 매우 느리다는 것입니다. 결국 완전한 응답을 받지만 Jenkins 대시보드와 같은 것을 수신하는 데 최대 5분이 걸립니다.
나는 NGINX와 Go에서 구현된 일부 REST API를 통해 제공되는 간단한 정적 HTML 페이지를 시도했습니다. 결과는 항상 동일합니다. 결국 데이터를 얻지만 터무니없는 시간이 걸립니다.
내 HAproxy 구성은 다음과 같습니다.
global
log /var/run/log local0 info
log /var/run/log local0 notice
daemon
maxconn 8000
tune.ssl.default-dh-param 2048
user nobody
group nobody
defaults
log global
option httplog
option dontlognull
mode http
timeout connect 5s
timeout client 1min
timeout server 1min
option forwardfor
option http-server-close
errorfile 400 /usr/local/etc/haproxy/errorfiles/400.http
errorfile 403 /usr/local/etc/haproxy/errorfiles/403.http
errorfile 408 /usr/local/etc/haproxy/errorfiles/408.http
errorfile 500 /usr/local/etc/haproxy/errorfiles/500.http
errorfile 502 /usr/local/etc/haproxy/errorfiles/502.http
errorfile 503 /usr/local/etc/haproxy/errorfiles/503.http
errorfile 504 /usr/local/etc/haproxy/errorfiles/504.http
frontend http-in
bind *:80
bind *:443 ssl crt /usr/local/etc/haproxy/certs/foo.my.org.pem
mode http
use_backend jenkins if { hdr(host) -i foo.my.org }
use_backend test if { hdr(host) -i bar.my.org }
default_backend test
backend jenkins
server jenkins1 <vpn_ip>:8180
mode http
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
reqrep ^([^\ :]*)\ /(.*) \1\ /\2
acl response-is-redirect res.hdr(Location) -m found
rspirep ^Location:\ (http)://<vpn_ip>:8180/(.*) Location:\ https://foo.my.org:443/\2 if response-is-redirect
backend test
server web01 <vpn_ip>:80
추가 정보:
- 관련된 모든 기계는 데이터 센터에 위치하며 1G/1G 인터넷 연결 기능을 갖추고 있습니다.
- 모든 머신은 FreeBSD 11 64비트를 실행합니다.
- 모든 컴퓨터의 OpenVPN 버전 2.4.4
- HAproxy 버전 1.7.9
- OpenVPN은 TCP 모드에서 실행됩니다.
- Jenkins의 HAproxy 백엔드 구성은 다음에서 제공된 대로 가져옵니다.젠킨스 문서그러나 언급한 바와 같이 정적 HTML 콘텐츠 웹 서버와 REST API 웹 서비스에도 동일한 문제가 존재합니다.
Jenkins 사이트에 액세스할 때 발생하는 HAproxy 로그는 다음과 같습니다.
Feb 27 01:32:24 hostname haproxy[5539]: 213.144.130.227:60243 [27/Feb/2018:01:32:24.093] http-in~ jenkins/jenkins1 0/0/13/134/161 302 153 - - ---- 5/5/0/0/0 0/0 "GET /jenkins HTTP/1.1"
Feb 27 01:32:24 hostname haproxy[5539]: 213.144.130.227:19404 [27/Feb/2018:01:32:24.255] http-in~ jenkins/jenkins1 0/0/25/174/212 200 4492 - - ---- 5/5/0/0/0 0/0 "GET /jenkins/ HTTP/1.1"
Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:16321 [27/Feb/2018:01:32:25.330] http-in~ jenkins/jenkins1 0/0/13/30/54 200 8560 - - ---- 6/6/4/4/0 0/0 "GET /jenkins/static/aeed77bb/scripts/yui/datasource/datasource-min.js HTTP/1.1"
Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:54637 [27/Feb/2018:01:32:25.330] http-in~ jenkins/jenkins1 0/0/27/29/58 200 7585 - - ---- 6/6/3/4/0 0/0 "GET /jenkins/static/aeed77bb/scripts/yui/autocomplete/autocomplete-min.js HTTP/1.1"Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:59247 [27/Feb/2018:01:32:25.361] http-in~ jenkins/jenkins1 0/0/25/16/51 200 9602 - - ---- 6/6/2/3/0 0/0 "GET /jenkins/static/aeed77bb/jsbundles/page-init.js HTTP/1.1"
Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:40637 [27/Feb/2018:01:32:25.332] http-in~ jenkins/jenkins1 0/0/38/18/81 200 16212 - - ---- 6/6/1/1/0 0/0 "GET /jenkins/static/aeed77bb/scripts/yui/menu/menu-min.js HTTP/1.1"
Feb 27 01:32:25 hostname haproxy[5539]: 213.144.130.227:10976 [27/Feb/2018:01:32:25.333] http-in~ jenkins/jenkins1 0/0/37/30/95 200 29110 - - ---- 6/6/0/0/0 0/0 "GET /jenkins/static/aeed77bb/scripts/hudson-behavior.js HTTP/1.1"
OpenVPN 때문일 수 있나요?
편집 1:그동안 저는 HAproxy 구성에서 웹 서버의 공용 IP 주소를 직접 사용하여 OpenVPN 없이 이것을 테스트했습니다. 결과는 똑같습니다.
답변1
귀하의 로그에는 5분 대기 시간을 설명할 만큼 충분한 정보가 포함되어 있지 않습니다. 대기 시간은 2초 미만입니다. 하지만 여기서 중요한 점은 다음과 같습니다.
option http-server-close
이는 WAN 링크 반대쪽에 있는 백엔드에는 적합하지 않습니다. 실제로 이 기능이 필요한 경우 백엔드 서버에 대한 지연 시간(예: 로컬)이 매우 짧은 HAProxy에 있어야 합니다.
타이머 값 에 많은 양의 지터가 있음을 확인하십시오 Tc. 이는 다음과 같은 로그 필드의 세 번째 값입니다.
Tq/Tw/Tc/Tr/Tt
따라서 첫 번째 항목인 에서 0/0/13/134/161값 Tc은 13ms입니다. Tc는 백엔드에 대한 연결을 설정하는 데 필요한 시간이므로 여기서 볼 수 있는 것은 왕복 지터가 거의 통제 불능 상태이며 어떤 경우에는 이 값의 거의 3배로 점프한다는 것입니다. 이것이 백엔드 서버의 리소스 부족으로 인한 것이 아니라고 가정하면 이는 TCP 모드에서 OpenVPN을 사용한 결과일 가능성이 높습니다. 반드시 그런 것은 아니지만 일부 패킷 손실을 나타낼 수도 있습니다.
TCP(OpenVPN) 내에서 TCP(HTTP)를 터널링하고 있는데, 이는 일반적으로 비대화형 애플리케이션과 지터가 중요하지 않은 애플리케이션에 적합하지만 그렇지 않은 경우에는 적합하지 않습니다. (예를 들어 다음을 참조하세요.TCP를 통한 TCP가 나쁜 생각인 이유깨끗한 네트워크에서 이 구성을 완전히 피할 이유는 충분하지 않지만 잠재적인 붕괴 시나리오 중 하나에 대해 논의합니다.) 제가 OpenVPN의 결함이 아니라고 가정한 바에 따르면 TCP 터널은 UDP 터널과 동일한 일관된 대기 시간을 갖지 않습니다. 터널을 통해 핑을 보내면 이 지터가 핑 응답 시간에 전달되는 것을 볼 수 있습니다.
터널을 UDP로 변경하면 문제가 사라져야 합니다. 그러나 TCP 터널 사용의 부작용이라고 가정할 때 이 지터의 중요성과 성능에 미치는 영향은 아마도 를 사용하여 과장되었을 수 있습니다 option http-server-close. 각 요청은 HAProxy와 백엔드 사이에 새로운 연결을 설정해야 합니다.
OpenVPN 터널이 를 사용하여 압축된 경우 comp-lzo이를 비활성화하는 것도 고려하십시오. 전송 시 잠재적인 비용 절감이 오버헤드보다 더 클 수 있기 때문입니다.
답변2
이는 방화벽/NAT 구성에 문제가 있는 것으로 밝혀졌습니다.
그러나 누구든지 이 문제를 발견하면 HAproxy 커뮤니티에서 더 많은 도움을 받을 수 있습니다.https://discourse.haproxy.org/t/reverse-proxy-very-slow-page-load/2172