Amazon EC2에 확장 가능하고 안정적인 haproxy 클러스터를 어떻게 배포 할 수 있습니까?


25

ELB가 제공하는 것 (대부분 L7 검사)보다 더 고급 기능이 필요하지만 EC2를 사용하는 haproxy와 같은 방식으로 하트 비트 및 고가용 성과 같은 것을 처리하는 방법은 명확하지 않습니다. 클러스터에 3 개 이상의 haproxy 노드가 필요할 가능성이 높으므로 두 노드 사이의 간단한 하트 비트가 작동하지 않습니다.

haproxy 노드 앞에 하트 비트 계층을 배치하는 것이 IPVS를 사용하는 방법이지만 EC2 클러스터가 변경 될 때 구성 변경을 처리합니다 (확장과 같은 의도적 변경 또는 의도하지 않은 손실 등) EC2 노드)는 사소한 것처럼 보입니다.

바람직하게는 솔루션은 적어도 2 개의 가용 영역에 걸쳐있을 것이다.

Qs에 대한 대답 : 아니요. 세션은 끈적 거리지 않습니다. 그렇습니다. SSL이 필요하지만 이론 상으로는 다른 설정에서 완전히 처리 할 수 ​​있습니다. SSL 트래픽을 비 SSL 트래픽과 다른 위치로 보낼 수 있습니다.


새로운 버전의 소프트웨어로 이동하는 트래픽이 서서히 증가하면서 카나리아 배포를 수행하는 방법을 연구 중이며, 이로 인해 어디에서 끝났는지 궁금합니다. Jesper의 제안 중 하나를 시도 했습니까?
Iain

답변:


14

저는 SmugMug 수준의 트래픽으로 AWS로드 밸런싱 솔루션을 구축 한 적이 없지만 이론과 AWS 서비스 만 생각하면 몇 가지 아이디어가 떠 오릅니다.

원래 질문에는로드 밸런싱 디자인에 영향을주는 몇 가지 사항이 누락되었습니다.

  1. 끈끈한 세션? 고정 세션을 사용하지 않고 모든로드 밸런서 (LB)가 라운드 로빈 (RR) 또는 임의 백엔드 선택을 사용하도록하는 것이 좋습니다. RR 또는 임의 백엔드 선택은 간단하고 확장 가능하며 모든 상황에서 균일 한로드 분배를 제공합니다.
  2. 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이 투자하고 확장 할 가능성이 가장 높습니다. 이것은 아마도 나의 첫 번째 선택 일 것입니다.


1
그래서 접근 방식 1을 좋아합니다. 기대했던 방향이지만 여전히 흥미로운 문제가 있습니다. 최소한은 아니지만 ELB가 전체 AZ 실패를 잘 처리하지 못한다는 것입니다 (우리가 이미 일어났던 일) ). 쉽지만 유쾌한 '솔루션'에는 AZ를 교차하도록 구성된 ELB 뒤에있는 프록시가 있어야합니다 (다른 AZ의 백업 클러스터가있을 수 있음). 각 AZ에 하나 이상의 haproxy가 있으면 괜찮습니다. 그러나 그것은 문제를 제거하지 않고 단지 모방합니다. 이 문제에 대한 아이디어가 있습니까?
Don MacAskill

@Don MacAskill : AWS에 대규모 서비스 다운 타임이 몇 번 있었지만 AWS에서 AZ 안정성보다 더 나은 것은 어렵다는 것을 알고 있습니다. 프론트 엔드의 다중 AZ 운영으로 전환하는 것은 전체 스택의 다중 AZ 운영을 향한 첫 번째 단계가 될 수 있으며 이는 뱀의 전체 주전자입니다.
Jesper M

@Don MacAskill : 하나의 옵션은 DynDNS Dynect-> ELB + L7 LB와 같은 지리 인식 DNS 해상도를 하나의 AZ 내부에서, 다른 ELB + L7을 다른 AZ에서 핫 대기 상태로 만드는 것입니다. Dynect는 지리를 인식하는 것 외에도 상태 점검을 수행합니다. DynDNS는 가동 시간에 대한 기록이 훌륭하지만, 지리 인식 DNS를 추가하는 것도 또 다른 SPOF입니다. 2 개의 AZ에서 Dynect +로드 밸런싱이 단 하나의 AWS AZ보다 장기 가동 시간이 더 좋은지 여부는 분명하지 않습니다. 의미하는 바에 대한 개요는 다중 AZ 데이터베이스를 참조하십시오. dev.bizo.com/2010/05/improving-global-application.html
Jesper M

@Don MacAskill : 마지막 한 가지-단일 ELB 인스턴스는 여러 AZ에 걸쳐있을 수 있습니다. EC2 지역에 걸쳐있을 수 없습니다 . 그러나 같은 지역에있는 두 개의 AZ에서 EL7을 L7 LB에 사용하는 것이 허용되는 경우 가장 간단 할 것입니다 ... "ELB는 전체 AZ 실패를 잘 처리하지 못합니다." 나는한다.
Jesper M

ELB 스팬 여러 AZS과 그것을 얻을 수없는 실패의 어떤 종류가 있는지 그래, 어떤 AZ에서 백엔드 노드 (그들이 과부하하고를 위, 아래, 반환 503s는 무엇이든), 최종 사용자는 이러한 오류를 참조 - 그것은 아무튼 ' 다른 AZ로 다시 라우팅하지 마십시오. 나는 그것이 계획되기를 바라고 있지만, 그것은 이미 우리를 물린 것입니다.
Don MacAskill

2

고정 세션을 수행하지 않거나 Tomcat / apache 스타일을 사용하는 경우 (LB에 상태를 저장하는 대신 nodeid를 sessionid에 추가), HAF를 프록시 그룹 앞에서 사용합니다. ELB에는 상태 확인 기능이 내장되어있어 프록시를 모니터링하고 풀에서 다운 할 수 있습니다. 하트 비트 장애 조치보다 설정이 훨씬 적습니다.

변경 사항을 전파하는 한 큰 대답이 없습니다. Puppet은 초기 구성 및 변경 구현에 적합하지만 노드 추가 / 제거에는 30 분 폴링 간격보다 빠른 응답을 원하는 경향이 있습니다.


1
좋은 솔루션입니다. 좋은 질문입니다. Amazon SNS를 사용하여 구성 변경 사항을 푸시 방식으로 전파 할 수 있습니다. haproxy 구성에서 노드를 추가 / 제거하려면 알림 시스템이 필요합니다.
Rafiq Maniar

백엔드 서버 (하프 프록시가 전달하는 서버)를 관리하는 또 다른 옵션은 각 백엔드 서버가 모든 HaProxies 또는 구성 서버 (정기 등록 (30 초 정도)를 보내도록하는 것입니다. 사망 한 경우 신속하게 등록이 취소됩니다 (어쨌든 haproxy는주의해야합니다). 새로운 것이 나오면 자동으로 회전합니다. 이것은 분명히 Netflix가하는 일입니다.
Ben Jencks

1

나는 그것을 직접 사용하지는 않았지만 많은 사람들이 EC2에서 이러한 종류의 문제를 처리하기 위해 꼭두각시를 사용하는 것을 언급했습니다.


예, EC2의 Puppet을 사용하면 클러스터를 매우 간단하게 관리 할 수 ​​있습니다. 마이크로 인스턴스를 만들어 꼭두각시 마스터로 사용하십시오.
Tom O'Connor 1

1
우리는 데이터 센터에서 퍼펫을 사용하지만 아직 EC2에서는 시도하지 않았습니다. 꼭두각시 EC2는 어떻게 ec2-describe-instances 또는 무언가를 사용하여 노드를 찾고 해당 출력에 따라 자동으로 구성 / 재구성 할 수 있도록 인식합니까? 그리고 꼭두각시 마스터가 갑자기 사라지는 것을 어떻게 처리하겠습니까?
Don MacAskill

왜 갑자기 사라질까 요?
Tom O'Connor

EC2를 인식하지는 않지만 시작할 때 서명 할 새 노드가 표시되도록 설정하고 외부 노드 스크립트를 사용하여이를 설명 할 수 있습니다. 나는 SimpleDB (외부 노드)와 SQS (새로운 노드에 대한 서명 요청 큐)로 이것을하기 위해 파이썬을 썼다. 우분투 개발자는 S3를 사용하여 스크립트를 작성했습니다 : ubuntumathiaz.wordpress.com/2010/04/07/…
Ben Jencks

꼭두각시 마스터가 갑자기 사라지면 매니페스트를 실행하지 않습니다. 즉, 어떤 상태에
있더라도
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.