AX 로드 밸런싱 구성 경험 설명(2) - 세션 유지
실제로 세션 유지 메커니즘과 부하 균형의 기본 기능은 완전히 모순된다.부하 균형은 클라이언트의 연결, 요청의 균형을 백엔드에 있는 여러 서버로 전송하여 한 서버의 부하가 너무 높지 않도록 하고자 한다.세션 유지 메커니즘은 일부 요청을 같은 서버로 전송하여 처리해야 한다.따라서 실제 배치 환경에서 우리는 응용 환경의 특징에 따라 적당한 회화 유지 메커니즘을 선택해야 한다.
연결과 세션의 차이
세션 유지 기술을 소개하기 전에, 우리는 먼저 연결이 무엇인지, 세션이 무엇인지, 그리고 이 두 가지 개념을 이해하는 데 시간을 들여야 한다.
특히 강조해야 할 것은 우리가 부하 균형만 이야기한다면 세션과 연결은 종종 같은 의미를 가진다.그러나 우리가 개발자와 이 용어들을 소통할 때 이 두 용어는 전혀 다른 의미를 가진다.많은 독자들이 이 중의 차이에 주의할 수 있기를 바란다.본고에서 내가 중점적으로 설명하고 싶은 것은 개발자가 보는 연결과 회화의 의미이다.
일반적으로 일반적인 클라이언트나 서버에서 우리는 같은 [원본 주소: 포트]와 같은 [목적 주소: 포트]를 가진 데이터 패키지를 연결로 정의합니다.다음 표는 Windows 시스템에서 명령 넷stat – an으로 출력되는 일부 시스템 연결 상태입니다.
- C:\>netstat -an
-
-
-
-
-
- ...< >...
- TCP 172.31.20.53:47669 122.225.67.240:80 ESTABLISHED
- TCP 172.31.20.53:47670 122.225.67.240:80 ESTABLISHED
- TCP 172.31.20.53:47671 122.228.243.240:80 ESTABLISHED
- TCP 172.31.20.53:47672 110.75.34.138:80 TIME_WAIT
- TCP 172.31.20.53:47673 110.75.34.138:80 TIME_WAIT
- TCP 172.31.20.53:47674 110.75.34.138:80 TIME_WAIT
- TCP 172.31.20.53:47675 122.225.67.240:80 ESTABLISHED
- TCP 172.31.20.53:47676 122.225.67.240:80 ESTABLISHED
- TCP 172.31.20.53:47677 122.228.243.240:80 ESTABLISHED
- TCP 172.31.20.53:47679 110.75.24.105:80 ESTABLISHED
- TCP 172.31.20.53:47681 122.225.67.240:80 ESTABLISHED
- TCP 172.31.20.53:47682 122.225.67.240:80 ESTABLISHED
- TCP 172.31.20.53:47683 60.191.143.240:80 ESTABLISHED
- TCP 172.31.20.53:47684 60.191.143.240:80 ESTABLISHED
- TCP 192.168.1.4:18231 203.208.46.29:443 CLOSE_WAIT
- ...< >...
부하 균형에 대해 말하자면 상황은 약간 변화가 생겼다.로드 밸런싱은 동일한 [소스 IP: 포트]에서 동일한 [목적 IP: 포트]의 패킷으로 전송되고 NAT 기술을 통해 일부 변환된 후 백엔드의 고정된 서버로 전송됩니다.다음 표에서 보듯이 두 TCP 연결에는 동일한 소스 주소가 있지만 소스 포트가 다르기 때문에 AX 로드 밸런싱은 두 개의 서로 다른 연결로 인식되고 두 개의 서로 다른 서버로 전송되어 처리됩니다.
- AX#show session
- ...< >...
-
- Prot Forward Source Forward Dest Reverse Source Reverse Dest Age Hash
- -----------------------------------------------------------------------------------------------------------
- Tcp 103.104.157.122:1619 61.22.215.151:80 172.30.2.83:80 103.104.157.122:1619 60 1
-
- Tcp 103.104.157.122:1621 61.22.215.151:80 172.30.2.84:80 103.104.157.122:1621 120 3
-
- ...< >...
같은 연결의 데이터 패키지에 대해 부하 균형은 NAT 변환을 한 후 백엔드에 고정된 서버로 전송하여 처리한다. 이것은 부하 균형의 가장 기본적이고 원시적인 기능이다.부하 균형 시스템 내부에는 이러한 연결 상황을 기록하는 표가 있습니다. 예를 들어 [소스 IP: 포트], [목적 IP: 포트], [서버 IP: 포트], 유휴 시간 초과 (Idle Timeout) 등입니다.여기에 시간 초과의 의미와 정의를 특별히 설명해야 한다.
부하 균형 내부 기록 연결 상태의 이 시계는 시스템의 메모리 자원을 소모해야 하기 때문에 이 시계는 무한히 클 수 없고 모든 공장에 일정한 제한이 있을 것이다.이 표의 크기는 일반적으로 최대 병렬 연결 수, 즉 시스템이 동시에 수용할 수 있는 연결 수량이라고 부른다.이러한 연결을 구축한 클라이언트나 서버에 이상한 상황이 발생하여 연결이 정상적으로 종료되지 못할 수 있음을 감안하여 부하가 균형이 잡힌 현재 연결 상태 표에 빈 시간 초과 파라미터를 설계하였다.이 매개 변수는 이 연결이 일정 시간 동안 유량이 통과되지 않을 때 부하 균형이 자동으로 이 연결 항목을 삭제하고 시스템 자원을 방출하는 것으로 정의됩니다.AX에서 이 여유 시간 초과 시간은 일반적으로 120초로 설정됩니다.즉, 120초 이내에 AX가 클라이언트 또는 서버에서 데이터 패키지를 받지 못하면 AX는 시스템 자원을 방출하기 위해 이 연결을 자발적으로 삭제합니다.
여기서 이 파라미터를 강조하는 것은 다음에 세션 유지 메커니즘을 소개할 때 언급한 세션 유지 시간과 차이가 있기 때문이다.
연결의 개념을 이해하면 회화의 개념에 대해 비교적 쉽게 이해할 수 있다.개발자의 눈에는 일반적으로 사용자가 응용 시스템에 로그인하여 사무 처리를 하고 응용 시스템을 종료할 때까지 전체 과정을 가리킨다.따라서 같은 세션에 대해 클라이언트가 여러 개의 연결을 만들어 처리할 수 있습니다.클라이언트와 서버 사이에 부하 균형 장치를 배치하면 이 여러 연결이 다른 서버로 전송되어 처리될 가능성이 높다.서버 간에 세션 정보의 동기화 메커니즘이 없으면 다른 서버가 사용자의 신분을 식별하지 못해 사용자가 응용 시스템과 상호작용을 할 때 이상이 발생할 수 있다.일반적인 예외 장면은 다음과 같습니다.
클라이언트가 정확한 사용자 이름과 암호를 입력했지만 로그인 페이지로 넘어가 로그인을 요구합니다.
클라이언트가 장바구니에 넣은 물건을 잃어버렸습니다.
따라서 세션 유지 메커니즘의 의미는 같은 클라이언트의 요청을 백엔드와 같은 서버로 전송하여 처리하는 데 있다.다시 말하면 클라이언트와 서버 사이에 만들어진 여러 개의 연결을 같은 서버에 보내 처리하는 것이다.
일반적인 세션 유지 메커니즘 소개
소스 주소 세션 유지
소스 주소 세션은 클라이언트의 소스 주소 정보를 이용하여 로드 밸런싱을 유지하여 동일한 소스 IP에서 유래한 모든 연결을 같은 클라이언트로 인식하고 이러한 연결을 같은 서버로 전송하여 처리합니다.소스 주소 세션 유지 메커니즘이 활성화되면 AX 로드 밸런싱은 새로운 연결 요청을 받을 때 시스템의 소스 주소 세션 유지 테이블을 먼저 조회하고 IP 주소에 해당하는 서버 테이블 항목을 조회하면 현재 테이블 항목에 해당하는 서버에 따라 연결합니다. 소스 IP에 해당하는 서버가 조회되지 않으면 현재 설정된 알고리즘에 따라 서버를 선택합니다.또한 현재 연결에 대응하는 서버를 원본 주소 세션 유지표에 기록합니다.이렇게 하면 소스 IP에 새로운 연결 요청이 있을 때 이 표에 따라 백엔드의 서버 자원을 선택합니다.
소스 주소 세션 유지 메커니즘은 매우 간단하면서도 매우 효율적인 세션 유지 메커니즘이다.그러나 이런 간단함으로 인해 부하 균형이 클라이언트를 정확하게 식별하지 못하고 백엔드 서버의 부하 분배가 고르지 않다.특히 대량의 클라이언트가 같은 NAT 주소를 공유하여 서버 자원에 접근할 때 어떤 서버의 부하 분배가 너무 높아진다.또한 부하 균형 시스템 내부에 세션 유지표를 저장하는 것도 일정한 자원을 차지하기 때문에 클라이언트의 수가 많을 때 세션 유지표가 소모되는 문제를 초래할 수 있다.
쿠키 세션 유지
쿠키 세션 유지는 HTTP 프로토콜의 쿠키 기능을 이용하여 세션 유지 기능을 실현하는 것이다.클라이언트의 요청에 부하 균형 설정된 쿠키 정보가 있으면 부하 균형은 쿠키의 정보에 따라 서버를 선택한다.클라이언트의 요청에 쿠키 정보가 없으면 부하 균형은 알고리즘에 따라 서버를 선택하고 서버가 응답하는response 헤더에 쿠키 정보를 삽입합니다.이렇게 하면 이 클라이언트가 다시 서버에 접근할 때 이 클라이언트의 요청이 같은 서버로 전송되어 처리될 것을 확보할 수 있다.
원본 주소 세션 유지 메커니즘에 비해 쿠키 세션은 클라이언트를 더욱 정확하게 식별할 수 있어 대량의 클라이언트가 같은 NAT 주소를 공유하여 서버 자원에 접근할 때 원본 주소 세션 유지로 인해 단일 서버의 부하가 너무 높은 문제를 피할 수 있다.또한 부하 균형은 클라이언트가 요청한 쿠키 정보를 분석함으로써 서버의 선택을 결정하기 때문에 부하 균형은 시스템에서 세션 항목을 유지할 필요가 없기 때문에 세션 항목의 수량에 제한이 없다.그러나 쿠키 세션 유지 메커니즘은 원본 주소 세션보다 더 많은 제한이 존재한다.
우선, 쿠키 세션은 B/S 구조의 응용 프로그램에서만 사용할 수 있다. 즉, 쿠키 세션은 HTTP 프로토콜에서만 작동할 수 있다.간단합니다. 비HTTP 프로토콜은 쿠키 삽입을 지원하지 않습니다.
그 다음으로 브라우저가 쿠키를 지원하지 않으면 쿠키 세션 유지 메커니즘을 설정해도 쿠키 세션 유지 메커니즘은 효과가 없다.
셋째, 쿠키 세션 유지 메커니즘에서 부하 균형의 현재 시스템 시간에 따라 기한이 지난 시간을 계산하고 이 시간을 쿠키가 효력을 잃은 시간으로 설정해야 하기 때문에 부하 균형의 시스템 시간에 큰 오차가 있어서는 안 된다. 그렇지 않으면 세션 유지 메커니즘이 효력을 잃을 수 있다.
세 번째 문제에 대해 우리는 부하 균형의 시스템 시간이 정상적인 시계보다 20분 느리고 세션이 15분으로 유지되면 클라이언트가 부하 균형이 삽입된 쿠키를 받은 후에 이 쿠키가 효력을 잃었다고 생각할 수 있다. 후속적인 http 요청에서 부하 균형이 삽입된 세션 유지에 사용되는 쿠키가 없을 것이다.
이 두 가지 일반적인 세션 유지 메커니즘의 장점과 단점을 간단히 요약합니다.
방법
이점
결점
적용 장면
소스 주소 세션 유지
적용 범위가 광범위하다
로드 밸런싱 없이 정확한 시계 유지
클라이언트 요청이나 응답을 수정할 필요가 없습니다.
세션 테이블 유지 관리 필요
클라이언트 식별은 원본 주소 정보에만 의존하여 정확하지 않다
다양한 B/S, C/S 어플리케이션
세션 유지 시간이 짧은 응용 프로그램 필요
고성능이 필요한 장면
쿠키 세션 유지
클라이언트 식별 정확성
B/S 아키텍처만 지원
클라이언트가 쿠키를 지원해야 합니다.
로드 밸런싱이 필요한 정확한 시스템 시계
B/S 아키텍처 적용
세션 유지 시간이 긴 응용 프로그램 필요
다음 글에서 우리는 여전히 A10의 AX 부하 균형을 예로 들어 구체적인 장면에서 세션 유지 메커니즘을 어떻게 설정하고 세션 유지를 실현하는 토대에서 더욱 균형적인 부하 클라이언트 요청을 할 수 있는지 소개한다.
E.S.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Haproxy 웹 클러스터 구축실험 준비: Haproxy 서버 1대, Nginx 서버 2대, 클라이언트 1대(로컬 컴퓨터 사용) Nginx 서버: ### 참고: 둘 다 비슷한 작업을 수행해야 합니다. Haproxy 서비스: 테스트: 클라이언트가 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
