haproxy : 높은로드 상태에서 기존 세션 유지, 새로운 도착시 '503'제공


12

제목에서 말하는 것을 수행하려고 시도 : 높은 부하로 기존 세션을 유지하고 새로 도착한 방문자에게 503 메시지를 제공합니다.

문제 : 작동하지만 세션은 약 90 초 이상 지속되지 않습니다.

현재 결과에 누락 된 시간 제한 설정이 있는지 궁금합니다.

목적

haproxy를 얻으려고합니다.

  • 프런트 엔드의 총 세션 수가 특정 임계 값 미만인 경우 세션에 대한 요청 을 backend-001로 보냅니다 .
  • 프론트 엔드의 총 세션 수가 해당 임계 값을 초과하면 세션에 503 오류를 제공합니다.
  • 세션 수가 임계 값을 초과하더라도 기존 세션에 대한 요청 허용

이런 식으로, 다단계 양식을 작성하는 중간에있는 방문자는 503 오류로 놀라지 않을 것이며, 새로운 방문자는 "지금 우리가 바쁘기 때문에 나중에 다시 오십시오"라고 말할 수 있습니다.

설정

설정은 다음과 같습니다.

            {visitors}
                ↓ 
            [haproxy]
                ↓ 
[rails app on unicorn served by nginx]   (right now just one 
                                            backend: 'backend-001')

현재 접근

위의 목적을 달성하기 위해 아래 구성을 사용하고 있습니다.

이것은 테스트를보다 쉽게하기 위해 매우 낮은 한계 (프론트 엔드의 10 개 연결 (fe_conn gt 10))로 테스트하기위한 것입니다.

서버를 약간의 부하로두기 위해 다음과 같이 httperf를 사용하고 있습니다.

httperf --hog --server staging.machine.tld --uri / do_some_things --wsess = 500,10,30 --rate 2

global
    daemon
    maxconn 10000

defaults
    mode        http
    timeout connect 6s
    timeout client  60s
    timeout server  60s
    balance roundrobin
    option http-server-close

frontend http-in
    bind [PUBLIC_IP]:80

    default_backend backend-001

    acl too_many fe_conn gt 10
    use_backend b_too_many if too_many

backend backend-001
    fullconn 10
    appsession _session_id len 128 timeout 7200s

    cookie SERVERID insert maxidle 7200s
    server Server1 127.0.10.1:80 cookie backend-001 check

backend b_too_many
    errorfile 503 /var/www/50x.html

문제

위에서 언급했듯이 문제는 거의 효과가 있지만 세션은 약 90 초를 넘지 않습니다.

계속 클릭하면 10 개의 세션이 바쁠 때에도 세션을 유지하게됩니다.

다른 브라우저 인스턴스로 서버에서 페이지를 열려고하면 503 오류가 발생합니다.

그래서 나는 거의 거기에있는 것처럼 보입니다. 누구든지 짧은 세션 시간을 일으키는 원인을 알고 있습니까?

그리고 특히 내가 고칠 수있는 방법 :)

(편집 : '서버'라인에서 'weight 1 maxconn 10'을 제거하고 관련성이 없으며 혼동 할 수 있습니다) (두 번째 편집 : 프론트 엔드의 '10 세션 '을'프론트 엔드의 10 연결 '로 수정)


바보 같은 질문 일 수 있습니다-nginx의 keep_alive 설정은 무엇입니까? 분명히 기본적으로 75입니다. 이것이 문제 일 수 있습니까?
Aidan Kane

답변:


4

불행히도 응용 프로그램 수준 세션과의 연결이 완전히 혼란스러워 보입니다. 사이트를 방문하는 사용자에게는 쿠키가있을 수 있습니다. 쿠키는 반드시 그럴 필요는 없지만 연결을 소유하고 있다고 생각합니다. 개체를 가져오고 페이지를 탐색하는 데 필요한만큼의 연결을 열 수 있습니다.

관찰중인 90 초는 유휴 연결에 대한 브라우저의 활성 유지 시간 초과입니다.

원하는 것을 얻을 수는 있지만 방문자가 새로운 것인지 아닌지를 알아 내기 위해 요청에 지속성 쿠키의 존재를 고려해야하기 때문에 그보다 조금 더 복잡합니다.

또한 일반적으로 프런트 엔드 연결 수보다 서버 당 평균 연결 수를 사용하는 것이 더 효율적입니다. 서버가 죽으면이 숫자를 다시 조정해야하기 때문입니다. 가장 효율적인 방법은 큐를 사용하도록 서버 maxconn 값을 설정하고 avg_queue를 사용하여 제한이 서버의 평균 큐 요청 수에 적용되도록하는 것입니다. 이를 통해 기존 방문자로 인해로드가 증가 할 때 새로운 사용자를 다른 백엔드로 부드럽게 이동시키면서 알려진 방문자를 올바르게 처리 할 수 ​​있습니다.


1
감사합니다 감사합니다 그것은 많은 것을 정리했다. 이제 hdr_sub ( "hdr_sub (cookie) SERVERID = backend-001")로 백엔드 쿠키를 검사하여 다른 작업을 수행했습니다. 작업 설정이 완료되면 게시하겠습니다.
Apenootje
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.