ELB가 제공하는 것 (대부분 L7 검사)보다 더 고급 기능이 필요하지만 EC2를 사용하는 haproxy와 같은 방식으로 하트 비트 및 고가용 성과 같은 것을 처리하는 방법은 명확하지 않습니다. 클러스터에 3 개 이상의 haproxy 노드가 필요할 가능성이 높으므로 두 노드 사이의 간단한 하트 비트가 작동하지 않습니다.
haproxy 노드 앞에 하트 비트 계층을 배치하는 것이 IPVS를 사용하는 방법이지만 EC2 클러스터가 변경 될 때 구성 변경을 처리합니다 (확장과 같은 의도적 변경 또는 의도하지 않은 손실 등) EC2 노드)는 사소한 것처럼 보입니다.
바람직하게는 솔루션은 적어도 2 개의 가용 영역에 걸쳐있을 것이다.
Qs에 대한 대답 : 아니요. 세션은 끈적 거리지 않습니다. 그렇습니다. SSL이 필요하지만 이론 상으로는 다른 설정에서 완전히 처리 할 수 있습니다. SSL 트래픽을 비 SSL 트래픽과 다른 위치로 보낼 수 있습니다.
답변
저는 SmugMug 수준의 트래픽으로 AWS로드 밸런싱 솔루션을 구축 한 적이 없지만 이론과 AWS 서비스 만 생각하면 몇 가지 아이디어가 떠 오릅니다.
원래 질문에는로드 밸런싱 디자인에 영향을주는 몇 가지 사항이 누락되었습니다.
- 끈끈한 세션? 고정 세션을 사용하지 않고 모든로드 밸런서 (LB)가 라운드 로빈 (RR) 또는 임의 백엔드 선택을 사용하도록하는 것이 좋습니다. RR 또는 임의 백엔드 선택은 간단하고 확장 가능하며 모든 상황에서 균일 한로드 분배를 제공합니다.
- SSL 여부 SSL 사용 여부와 요청 비율에 따라 일반적으로로드 균형 조정 디자인에 영향을줍니다. 인증서 처리를 단순화하고 SSL CPU로드를 웹 응용 프로그램 서버로부터 멀리 유지하려면 가능한 한 빨리 SSL을 종료하는 것이 좋습니다.
로드 밸런싱 계층 자체를 고 가용성 으로 유지하는 방법의 관점에서 대답하고 있습니다. 애플리케이션 서버 HA를 유지하는 것은 L7로드 밸런서에 내장 된 상태 점검으로 수행됩니다.
좋아, 몇 가지 아이디어가 작동해야합니다.
1) “AWS 방식”:
- 첫 번째 계층은 맨 앞에 L4 (TCP / IP) 모드에서 ELB를 사용합니다.
- 두 번째 계층에서는 선택한 L7로드 밸런서 (nginx, HAProxy, Apache 등)와 함께 EC2 인스턴스를 사용하십시오.
이점 / 아이디어 : L7로드 밸런서는 모두 동일한 AMI에서 복제되고 동일한 구성을 사용하는 매우 간단한 EC2 AMI 일 수 있습니다. 따라서 Amazon 도구는 모든 HA 요구를 처리 할 수 있습니다. ELB는 L7로드 밸런서를 모니터링합니다. L7 LB가 죽거나 응답이 없으면 ELB & Cloudwatch는 새로운 인스턴스를 자동으로 생성하여 ELB 풀로 가져옵니다.
2) “모니터링 방식의 DNS 라운드 로빈 :”
- 기본 DNS 라운드 로빈을 사용하여 몇 개의 IP 주소를 통해 대략적인 부하 분산을 얻을 수 있습니다. 사이트에 대해 3 개의 IP 주소를 게시한다고 가정 해 봅시다.
- 이 3 개의 IP 각각은 선택한 L7로드 밸런서를 사용하여 EC2 인스턴스에 바인딩 된 AWS EIA (Elastic IP Address)입니다.
- EC2 L7 LB가 종료되면 호환되는 사용자 에이전트 (브라우저) 는 다른 IP 중 하나만 사용해야 합니다.
- 외부 모니터링 서버를 설정하십시오. 3 개의 EIP 각각을 모니터하십시오. 응답이 없으면 AWS의 명령 줄 도구와 일부 스크립팅을 사용하여 EIP를 다른 EC2 인스턴스로 옮깁니다.
이점 / 아이디어 : 호환되는 사용자 에이전트는 응답하지 않으면 다른 IP 주소로 자동 전환해야합니다. 따라서 장애가 발생한 경우 1/3의 사용자에게만 영향을 미치며 대부분의 UA는 다른 IP로 자동 장애 조치되므로 아무런 통지도하지 않습니다. 또한 외부 모니터링 상자에 EIP가 응답하지 않으며 몇 분 내에 상황을 바로 잡을 수 있습니다.
3) HA 서버 쌍에 대한 DNS RR :
기본적으로 이것은 한 쌍의 서버간에 간단한 하트 비트를 제안하지만 Don ‘s는 자체적으로 제안하지만 여러 IP 주소에 대해 단순화되었습니다.
- DNS RR을 사용하여 서비스에 대한 여러 IP 주소를 게시하십시오. 위의 예에 따라 3 개의 IP를 게시한다고 가정 해 봅시다.
- 이러한 각 IP는 한 쌍 의 EC2 서버에 연결되므로 총 6 개의 EC2 인스턴스가 사용됩니다.
- 이러한 각 쌍은 AWS 도구와 함께 하트 비트 또는 다른 HA 솔루션을 사용하여 능동 / 수동 구성에서 하나의 IP 주소를 활성 상태로 유지합니다.
- 각 EC2 인스턴스에는 선택한 L7로드 밸런서가 설치되어 있습니다.
이점 / 아이디어 : AWS의 완전히 가상화 된 환경에서는 실제로 L4 서비스 및 페일 오버 모드에 대해 추론하기가 쉽지 않습니다. 하나의 IP 주소 만 유지하면서 한 쌍의 동일한 서버로 단순화함으로써 추론 및 테스트가 더욱 간단 해집니다.
결론 : 다시 한 번, 실제로 프로덕션에서는이 작업을 시도하지 않았습니다. 내 직감에서 L4 모드의 ELB 옵션 1 및 L7 LB의 자체 관리 EC2 인스턴스는 AWS 플랫폼의 정신과 가장 잘 일치하는 것으로 보이며 나중에 Amazon이 투자하고 확장 할 가능성이 가장 높습니다. 이것은 아마도 나의 첫 번째 선택 일 것입니다.
답변
고정 세션을 수행하지 않거나 Tomcat / apache 스타일을 사용하는 경우 (LB에 상태를 저장하는 대신 nodeid를 sessionid에 추가), HAF를 프록시 그룹 앞에서 사용합니다. ELB에는 상태 확인 기능이 내장되어있어 프록시를 모니터링하고 풀에서 다운 할 수 있습니다. 하트 비트 장애 조치보다 설정이 훨씬 적습니다.
변경 사항을 전파하는 한 큰 대답이 없습니다. Puppet은 초기 구성 및 변경 구현에 적합하지만 노드 추가 / 제거에는 30 분 폴링 간격보다 빠른 응답을 원하는 경향이 있습니다.
답변
나는 그것을 직접 사용하지는 않았지만 많은 사람들이 EC2에서 이러한 종류의 문제를 처리하기 위해 꼭두각시를 사용하는 것을 언급했습니다.