ssl, 로컬 세션 및로드 밸런싱에 관한 많은 질문이 상호 연결되어있는 것으로 보이 므로이 질문의 길이에 대해 미리 사과드립니다.
파일 기반 세션을 사용하는 웹 사이트가 있습니다. 사이트의 특성상 대부분은 http이지만 일부 섹션은 SSL입니다. 현재 파일 기반 세션으로 인해 모든 SSL 요청이 이전 http 요청과 동일한 서버에 충돌해야합니다.
시간 제약으로 인해 증가 된 http 및 ssl 트래픽을로드 밸런싱하는 가장 쉬운 방법을 원합니다.
고정로드 밸런싱 알고리즘에는 두 가지 옵션이 있습니다.
- IP 기반
- 쿠키 기반
ip 기반 솔루션은 작동하지만 해시 알고리즘은 서버가 다운되거나 추가 될 때 사용자가 이동하는 서버를 잠재적으로 변경하여 현재 파일 기반 세션 설정에서 바람직하지 않습니다. 또한 웹 사이트를 탐색하는 동안 사용자가 합법적으로 IP를 변경할 수 있다고 가정합니다.
쿠키 기반 알고리즘은 더 좋아 보이지만 ssl에 의해 암호화 될 때 쿠키를 검사 할 수 없으면 자체 문제가있는 것 같습니다.
나는 SSL을로드 밸런싱하는 방법에 대한 예를 찾고 있으며 쿠키 기반로드 밸런싱을 수행하고 다른 ssl 디코더를 추가하여 증가 된 ssl로드를 처리 할 수있는 설정의 명시 적 예를 찾을 수없는 것 같습니다.
내가 본 명시 적 예제의 대부분에는 브라우저 클라이언트와로드 밸런서 사이에 ssl 디코더 (일반적으로 하드웨어, apache_mod_ssl 또는 nginx)가 있습니다. 예제는 일반적으로 다음과 같은 것 같습니다 ( http://haproxy.1wt.eu/download/1.3/doc/architecture.txt 에서 수정 됨 ).
192.168.1.1 192.168.1.11-192.168.1.14
------- + ----------- + ----- + ----- + ----- +
| | | | |
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| LB1 | | A | | B | | C | | D |
+ ----- + + --- + + --- + + --- + + --- +
아파치 4 저렴한 웹 서버
mod_ssl
하프시
위 예제에서 ssl 디코딩 부분은 수평으로 확장 할 수없는 잠재적 병목 현상 인 것 같습니다.
haproxy를 살펴본 결과 다음과 같은 것을 허용하는 'mode tcp'옵션이있는 것 같습니다. 여러 개의 SSL 디코더를 가질 수 있습니다.
하프시
|
-------------
| |
ssl-decoder-1 ssl-decoder2
| |
-------------------
| | |
web1 web2 web3
haproxy가 SSL을 디코딩되지 않기 때문에, 이러한 설정에서, 당신이 클라이언트 IP를 잃게 나타납니다 https://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -에 대한
또한 nginx를 살펴 보았으며 수평 확장 가능한 ssl-decoders의 명시 적 예도 보지 못했습니다. 잠재적 인 병목 현상으로 nginx를 가진 사람들의 많은 사례가있는 것 같습니다. 그리고 적어도이 링크는 nginx가 "백엔드에 TCP 연결을 투명하게 전달하는 것을 지원하지 않는다"고 말함으로써 ip를 잃는 haproxy와 같은 설정 옵션을 가지고 있지 않다고 제안하는 것 같습니다. Apache를 전달하는 방법 SSL 트래픽 트로프 nginx 프록시? .
질문 :
- 트래픽 증가를 처리하기 위해 더 많은 SSL 디코더를 추가하는 설정의 예가 더없는 것 같습니다.
- ssl 디코딩 단계는 단지 이론적 인 병목 현상이며 실제로 말 그대로 트래픽이 많은 사이트를 제외하고 하나의 디코더로 충분할까요?
- 염두에 두어야 할 또 다른 해결책은 아마도 증가 된 SSL 요구 사항을 가진 사람은 중앙 집중식 세션 저장소를 가지고 있기 때문에 클라이언트가 순차적 요청에서 어떤 웹 서버에 충돌하는지는 중요하지 않습니다. 그런 다음 모든 웹 서버에서 mod_ssl 또는 이와 동등한 기능을 사용할 수 있습니다.
- 위에서 언급 한 haproxy 솔루션은 작동하는 것처럼 보이지만 (클라이언트 IP 문제 외에) 클라이언트 IP를 유지하면서 디코더 수를 늘려 작동하는 고정 쿠키 기반 소프트웨어로드 밸런서 솔루션을 가진 사람이 있거나 기술적으로 그렇지 않은 사람도 있습니다. 클라이언트 IP를 얻기 위해 요청을 디코딩해야하기 때문에 디코더 병목 현상이 발생할 수 있습니다.
내가 말한 모든 것이 사실이라고 가정하면, 이것들은 나의 선택으로 보입니다.
- IP 해싱 사용 (합법적으로 IP를 변경하는 사용자 및 서버 추가 및 삭제 시나리오에 적합하지 않음)
- ssl 요청을 건 드리는 첫 번째 프로그램으로 nginx 또는 mod_ssl을 사용하면 잠재적 인 ssl 디코딩 병목 현상이 발생합니다.
- ssl 요청을 만지는 첫 번째 프로그램으로 haproxy를 사용하여 수평 ssl 확장 성을 얻지 만 웹 서버 수준에서 ssl 요청에 대해 ip가 기록되지 않은 채로 살 수 있습니다 (아마도 일시적으로 ok)
- 장기적으로는 모바일 또는 중앙 집중식 세션 저장소로 이동하여 고정 세션을 불필요하게 만듭니다