HTTP로드 밸런싱과 많은 수의 지속적인 TCP 연결 (가능한 경우 50k 정도)을 필요로하는 VM을 사용하여 호스팅되도록 앱을 설정하고 있습니다 (아마 아마존이지만 돌로 설정되지는 않음). 데이터 양이 많지는 않지만 업데이트가 자주 발생합니다.
지금은로드 밸런서를 평가하고 있으며 HAProxy 아키텍처에 대해 약간 혼란스러워합니다. HAProxy를 사용하여 TCP 연결의 균형을 조정하면 모든 결과 트래픽이로드 밸런서를 통과해야합니까? 그렇다면 다른 솔루션 (LVS 또는 nginx_tcp_proxy_module)이 더 적합할까요?
답변:
HAProxy (많은로드 밸런서와 마찬가지로)는 일반적으로 두 개의 대화를 유지합니다. 프록시에는 클라이언트와의 세션 (이 경우 TCP)과 서버와의 다른 세션이 있습니다. 따라서 프록시를 사용하면로드 밸런서의 연결이 2 배가됩니다. 따라서 모든 트래픽은로드 밸런서를 통해 흐릅니다.
여러로드 밸런서에서 확장 할 때는 꼭 필요한 것은 아닙니다. 그러나이 작업을 수행하는 실용적이고 상당히 쉬운 방법은 두 개의 유동 IP 와이 두 IP 사이의 라운드 로빈 DNS 를 유지하는 것과 같은 것을 사용하는 것 입니다. keepalived를 사용하면로드 밸런서 중 하나가 다운되면 다른 하나가 두 IP를 모두 보유하므로이 방법으로 고 가용성을 얻을 수 있습니다. 즉,로드가있는 하나의 활성 haproxy 인스턴스로 괜찮을 것이라고 생각합니다.
HAProxy는 매우 잘 확장됩니다. 예를 들어, Stack Exchange 네트워크는 개방형 TCP 연결을 유지하는 웹 소켓을 사용합니다. 이 게시물을 게시하는 동안 VMware 가상 머신에 아무런 문제없이 143,000 개의 확립 된 TCP 소켓이 있습니다. VM의 CPU 사용량은 약 7 %입니다.
HAProxy를 사용한 이러한 설정으로 maxconn충분히 높게 설정하십시오 . 다음은 시작하기위한 HAProxy 구성의 예입니다.
frontend fe_websockets
bind 123.123.123.123:80
mode tcp
log global
option tcplog
timeout client 3600s
backlog 4096
maxconn 50000
default_backend be_nywebsockets
backend be_nywebsockets
mode tcp
option log-health-checks
option redispatch
option tcplog
balance roundrobin
server web1 10.0.0.1:1234
server web2 10.0.0.2:1234
timeout connect 1s
timeout queue 5s
timeout server 3600s
DSR (Direct Server Return)을 사용하고 구성 할 가능성이 있지만 이것은로드 밸런서와 관련이 없지만 tcp-stack (라우팅 테이블)에 구성됩니다. 우리는 이것을 대형 비디오 스트리밍 포털에 사용했습니다. 그것은 작동하지만 필요한 라우팅의 복잡성과 관련하여 상당한 양의 두통을 줄 것입니다.
따라서 사용과 단점을 철저히 고려하지 않고이 기술을 사용하지 않는 것이 좋습니다.
어쩌면 거기에서 시작하는 힌트가있을 수 있습니다.
즐기세요!