여러로드 밸런서를 사용하여 트래픽을 애플리케이션 서버로 리디렉션 할 수 있습니까?

로드 밸런싱을 처음 사용하고 여러로드 밸런서를 사용하여 트래픽을 내 애플리케이션 서버로 리디렉션 할 수 있는지 궁금합니다. 나는 이것이 어떻게 이루어질 수 있는지 정말로 이해하지 못한다. 도메인 이름이 특정 서버의 IP 주소 (이 경우 하나의로드 밸런서의 IP)와 일대일로 일치하지 않아야합니까? 각로드 밸런싱 서버에 다른 IP가있는 경우 두로드 밸런서 (또는 10 개의로드 밸런서 또는 50 또는 100)가 어떻게 요청을 수신 할 수 있습니까?

라운드 로빈 DNS를 사용하는 것은 고 가용성에 적합하지 않습니다. 한 서버가 오프라인 상태가 되어도 클라이언트는 계속 연결하여 시간 초과를 기다립니다.

이를 달성하는 다른 방법이 있습니다.
1) 액티브 / 패시브로드 밸런서
기본적으로 하나의로드 밸런서는 하나의 IP 주소에 대한 모든 트래픽을 처리합니다.
해당 밸런서가 중단되면 수동 노드가 뛰어 들어 IP를 인수합니다.
로드 밸런서는 거의 트래픽을 전달하는 것이므로 중소 규모의 사이트에서는 문제가 해결 될 수 있습니다.

2) 액티브 / 액티브로드 밸런서
동일한 트래픽 IP가 두 개 이상의로드 밸런서에 구성됩니다.
들어오는 트래픽은 모든로드 밸런서로 전송되지만 알고리즘은 어떤 밸런서가 응답해야하는지 선택하고 다른 모든 트래픽은 해당 트래픽을 버립니다.
간단히 생각하면 두 가지로드 밸런서가 있습니다.
요청하는 IP가 짝수로 끝나면로드 밸런서 A가 응답하고 그렇지 않으면로드 밸런서 B가 응답합니다.

물론 인프라가이를 지원해야하며 트래픽이 전송되었지만 폐기되어 오버 헤드가 발생합니다.
자세한 내용은 여기를 참조하십시오 : http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

로드 밸런서가있는 고 가용성은 일반적으로 여러 호스트 (예 :로드 밸런서)가 여러 가지 방법 중 하나로 하나의 공통 IP 주소에 응답 할 수 있는 가상 IP 주소 (VIP) 프로토콜을 사용하여 구현됩니다 (활성 / 수동, 활성 / 활성의 변형). .

이 프로토콜에는 많은 수가 있으며, 정규로드 밸런서에서 가장 많이 본 프로토콜은 VRRP 및 NLB입니다 (기기의 많은 설명되지 않은 블랙 박스 프로토콜). 라우터 및 방화벽으로 확장하면 CARP , HRSP , GLSP 등이 발생할 수도 있습니다 .

이 전략은 DNS로드 밸런싱에 비해 여러 가지 이점이 있으며, 이는보다 간단한 전략이며 다른 답변에서 처리됩니다.

예를 들어 DNS로드 밸런싱에는 다음과 같은 부담이 있습니다.

• DNS 캐싱 메커니즘의 느린 전환
• 제한된로드 밸런싱 알고리즘 (일반적으로 라운드 로빈)
• 클라이언트에 대한로드 밸런싱 결정 아웃소싱 (dns 레코드의 캐싱을 통해)
• 서버 (예 :로드 밸런서)가 회전하지 않을 때 서비스 대기열이 느려짐 ( ISP 및 클라이언트가 처리하는 DNS 레코드 TTL 기반 )
• 로드 밸런서 장애시 느린 장애 조치

HA에 가상 IP 프로토콜을 사용하면 다음과 같은 목표를 달성 할 수 있습니다.

• 로드 밸런서 중에서로드 밸런싱 알고리즘 선택
• 서버 중심로드 밸런싱 결정 (예 : 서비스 상태 기반 측정 및 라우팅 용이)
• 로드 밸런서가 회전하지 않으면 서비스 대기열이 더 빨리 배출됩니다.
• 로드 밸런서 오류시 즉각적인 페일 오버

자신의 시나리오에 가장 적합한 전략과 프로토콜을 아는 사람 만 있습니다.

요구 사항 : 하드웨어로드 밸런서, BGP 프로토콜 및 그 모든 것에 액세스 할 수없는 클라우드 또는 모든 유형의 환경에서 작동하는 실용적인 솔루션이 있어야합니다.

응용 프로그램의 소득 요청 번호는 알려지지 않았지만 두려움없이 증가 된 부하 기대치를 충족 할 수있을만큼 높아야합니다.

로깅 저장소 및 검색 앱과 같이 유사한로드 특성을 가진 응용 프로그램을 찾아 보겠습니다. 나는 하나를 발견했다 .

그들이 원하는 것:

1. 수집기 전체의 부하 균형
2. 수집기 중 하나가 죽거나 문제가 발생하는 경우 데이터를 계속 수집 할 수 있도록 내결함성을 제공합니다.
3. 로그 볼륨의 증가에 따라 수평으로 확장

그들은 ELB에 대해 무엇을 시도하고 배웠습니까?

1. 예상대로 작동하지 않습니다
2. 부하 증가로 인한 대기 시간 문제
3. 모니터링 시설이 충분하지 않습니다
4. 너무 많은 제한 (개방 포트 및 프로토콜 번호)

Route53으로 선택한 이유 :

1. "라운드 로빈은 매우 기본적인로드 밸런싱이지만 효율성 측면에서 우리에게 잘 작동합니다."
2. "Route 53 장애 조치 상태 점검을 활용합니다."
3. "콜렉터에 문제가있는 경우 Route 53은 자동으로 서비스에서 제외되며 고객에게는 아무런 영향이 없습니다."
4. Route 53에 사전 준비가 필요 없음

Route 53은 Loggly가 거대한 로그 볼륨, 예측할 수없는 변형 및 비즈니스의 지속적인 성장을 고려할 때 고성능 수집기를 활용하는 가장 좋은 방법으로 판명되었습니다. 수집기의 핵심 목적과 일치합니다. 손실없이 네트워크 회선 속도로 데이터를 수집하고 Loggly에서 사용하는 모든 AWS 서비스의 탄력성을 활용할 수 있습니다.

이 특정 예는 일부 시나리오 (로그 수집기, 광고 서비스 또는 이와 유사한)에서로드 밸런서가 중복되고 "DNS 상태 검사 라운드 로빈 솔루션"이 그 역할을 잘 수행함을 보여줍니다.

AWS 가 DNS 장애 복구에 대해 말한 내용을 살펴 보겠습니다 .

Route 53은 DNS 장애 조치를 통해 웹 사이트 중단을 감지하고 최종 사용자를 사용자가 지정한 대체 또는 백업 위치로 리디렉션 할 수 있습니다. Route 53 DNS 장애 조치는 상태 점검을 통해 정기적으로 전 세계 여러 위치에서 애플리케이션 엔드 포인트에 인터넷 요청을하여 애플리케이션의 각 엔드 포인트가 작동 중인지 작동 중지되었는지 확인합니다.

이 기술은 또한 ELB (참고 용이 아닌 필요하지 않음)를 더욱 강력하게 만들어줍니다. 다시 RR + Health Check를 기반으로합니다.

Route 53 DNS 장애 조치는 배후에서 ELB와 통합하여 이러한 모든 장애 시나리오를 처리합니다. 활성화되면 Route 53은 개별 ELB 노드에 대한 상태 확인을 자동으로 구성하고 관리합니다.

이제 장면 뒤에서 어떻게 작동하는지 봅시다 . 명백한 질문은 DNS 캐싱을 처리하는 방법입니다.

그러나 클라이언트와 Route 53 사이의 모든 계층에서 TTL을 준수하지 않으면 DNS 캐싱은 여전히 ​​문제가 될 수 있습니다 ( "긴 꼬리"문제는 이전 게시물 참조). "캐시 버스 팅"기술을 적용 할 수 있습니다. 고유 한 도메인에 요청을 보내다

("http://<unique-id>.<your-domain>") 

와일드 카드 리소스를 정의

Record "*.<your-domain>" to match it.

Algolia 는 "클라이언트 재시도 전략"을 도입 하여 클라이언트 (귀하의 JS)가 다음을 처리 할 수 ​​있다면 매우 효과적입니다.

결국 API 클라이언트에서 기본 재시도 전략을 구현했습니다. 각 API 클라이언트는 세 개의 다른 시스템에 액세스 할 수 있도록 개발되었습니다. USERIDID-1.algolia.io, USERID-2.algolia.io 및 USERID-3.algolia.io라는 세 가지 다른 DNS 레코드가 각 사용자를 나타냅니다. 첫 번째 구현은 레코드 중 하나를 무작위로 선택한 다음 실패시 다른 레코드로 다시 시도하는 것입니다.