레이어 4 및 레이어 7로드 밸런싱

데이터 센터에 레이어 4로드 밸런싱 솔루션을 사용하거나 레이어 7 솔루션을 사용하기로 결정했습니다. 불행히도 (제 정신을 위해) 내 유스 케이스는 두 솔루션이 모두 잘 작동하여 대부분의 약점을 피하고 실제로 다른 강점을 활용하지 않을 정도로 간단합니다. 어떤 솔루션을 사용하든 가용성과 처리량이 높아야합니다. 그러나 웹 서버 클러스터에 대한로드 밸런싱을 위해서만이를 사용할 계획이며, "고정"세션 관리 (쿠키 또는 IP), 복잡한 재 작성 규칙 또는이 문제에 대한 재 작성 규칙에 대한 요구 사항은 없습니다. 모든.

로드 밸런서는 데이터 센터 집계 계층에 독립적으로 연결하고 Rapid Spanning Tree와 스위치가 가상화에 사용하는 모든 독점 프로토콜을 사용하여 함께 병합되는 두 개의 스위치에 연결됩니다. 로드 밸런서는 크로스 오버 케이블을 통해 서로 가교됩니다. 클러스터의 모든 서버가 두 스위치에 모두 연결되어 있습니다. 로드 밸런서가해야 할 일은 트래픽을 포인팅하는 것입니다.

HTTP 일 뿐이므로 HAProxy 또는 nginx와 같은 계층 7로드 밸런싱 솔루션을 사용할 수 있습니다. 그러나 나는 또한 ldirectord 또는 keepalived 또는 무엇이든 LVS 프로젝트를 사용할 수 있습니다.

나는 그들이 볼 때 장단점을 깨려고 노력했지만, 결국은 씻겨 버린다. 무엇을 추천하고 왜 하시겠습니까? 뭔가 빠졌습니까?

haproxy와 같은 "L7"의 유용한 이점 중 하나는 쿠키를 사용하여 동일한 브라우저가 동일한 백엔드 서버를 공격 할 수 있다는 것입니다. 이렇게하면 클라이언트 히트 디버깅이 훨씬 쉬워집니다.

L4 밸런싱은 여러 백엔드 서버에서 단일 사용자를 반송 할 수 있습니다. (어떤 경우에는 유리하지만 디버깅 / 프로파일 링 관점에서 "L7"을 사용하는 것이 훨씬 더 중요합니다.)

편집 : HTTP 밸런싱 사용의 잠재적 인 속도 이점도 있습니다. 연결 유지 기능을 사용하면 클라이언트가 밸런서에 단일 TCP 세션을 설정 한 다음 새 TCP 세션을 다시 설정하지 않고도 많은 HIT를 보낼 수 있습니다 (3 방향 핸드 셰이크). 마찬가지로 많은 LB가 백엔드 시스템에 대한 연결 유지 세션을 유지하여 백엔드에서 동일한 핸드 셰이크를 수행 할 필요가 없습니다.

엄격한 TCP로드 밸런싱은이 두 가지를 쉽게 달성하지 못할 수 있습니다.

/ * FWIW : "L7"또는 "L4"라고 말하지 않고 HTTP 또는 TCP라고합니다. 그러나 OSI를 사용하여 일치하지 않는 것을 설명하는 것을 피하는 사람입니다. * /

무엇을 배포해야할지 확실치 않다면 기본적으로 단순하고 자연스러운 느낌을 가지십시오. 그것을 테스트하고 (아파치 벤치를 사용합니까?) 필요에 따라 작동하는지 확인하십시오. 나에게 HTTP LB가 더 자연 스럽습니다.

L7 밸런싱을 수행 할 때 이점이 없기 때문에 L4 밸런싱을 대신 사용합니다. 나는 너무 많이 희생하지 않고 가능한 한 간단하게 유지하는 것을 좋아합니다.

L7은 밸런서가 적절한 라우팅을 위해 패킷을 통과하는 패킷의 http 헤더를 검사하여 추가 오버 헤드를 추가하고 최종 사용자의 대기 시간을 약간 증가시킵니다. 아무 것도 얻지 못하면 무의미한 비용으로 보입니다.

일부 DNS 공급자는 간단한 장애 조치 기능이 있습니다. 요구 사항이 아닌 요구 사항에 대해 언급했지만, 필요한 모든 것이 다운 된 경우 장애 조치가있는 라운드 로빈 일 경우 zoneedit.com의 Failover를 사용할 수 있습니다 . HA 요구에 따라 충분할 수 있으며 아키텍처의 전체 계층을 건너 뛸 수 있습니다.