UDP 서버로드 밸런싱


10

나는 udp 서버를 가지고 있으며, 그것은 내 비즈니스 프로세스의 중심 부분입니다. 프로덕션 환경에서 예상되는로드를 처리하려면 서버 인스턴스가 2 ~ 3 개 필요합니다. 서버는 거의 전적으로 상태가없고, 대부분 데이터를 수집하며, 그 위의 계층은 여러 서버 인스턴스에서 발생할 수있는 최소량의 오래된 데이터를 처리하는 방법을 알고 있습니다.

제 질문은 서버간에로드 밸런싱을 어떻게 구현할 수 있습니까? 서버간에 요청을 가능한 한 고르게 분배하는 것을 선호합니다. 또한 클라이언트 X가 서버 y로 라우트 된 경우 X의 후속 요청이 서버 Y로 이동하고 Y가 과부하되지 않는 한 서버 Y로 이동하기를 원합니다.

그건 그렇고 그것은 .NET 시스템입니다 ... 무엇을 추천 하시겠습니까?


상태는 일종의 트랜잭션이 아니라 서버 내부에 있습니다. 상태는 서버가받는 데이터에서 서버가 집계하는 일부 데이터이며 간단한 WCF WebService를 사용하여 쿼리 할 수 ​​있습니다. 응용 프로그램은 UDP를 기반으로하며 결정에 동의하지 않지만 "Above my pay grade"

나는 현재 MS의 NLB를 시험하고 있는데 정상적으로 작동하고 충실도를 수행하지만 전체 네트워크에서 노이즈를 생성합니다 ...

또한 DNS가 없습니다 ... 아 그리고 그것은 완전한 의상 프로토콜입니다.


향후 참고를위한 참고 사항 – 많은 경우 중재자와 평판이 좋은 사용자가 스택 교환 사이트간에 질문을 이동할 수 있습니다. 이렇게하면 이미 배치 된 답변을 보존하는 데 도움이되므로 답변이없는 경우가 아니면 이전 답변을 삭제하여 실수로 답변하지 않는 것이 좋습니다. 이사 제안에 동의하는 경우 해당 효과에 의견을 추가하고 가능한 경우 운영자의 관심을 끌기 위해 게시물에 플래그를 지정하면 게시물이 자동으로 이동됩니다.
bdonlan

답변:


4

나는 udp 서버를 가지고있다. [...] 서버는 거의 전적으로 상태가 없다 [..] 충실도를 가진다. 만약 클라이언트 X가 서버 y로 라우팅 되었다면, X의 모든 후속 요청은 서버 Y로 가고 싶다. Y이고 과부하가되지 않는 한 현명합니다.

따라서 일부 응용 프로그램 상태를 유지하고 UDP 위에서 실행되는 비공개 응용 프로그램 프로토콜을 사용하고 있습니까? 당신은 어려운 방향으로 가고 있습니다. UDP는 신뢰할 수있는 데이터 전송이 아닙니다. 요점은 신뢰할 수있는 데이터 전송에 대한 인기있는 친구 TCP를 참조하십시오. '충실도'를 얻을 수있는 유일한 방법은 응용 프로그램 계층 프로토콜을 이해하고 현재 응용 프로그램 상태가 무엇인지 알고 그에 따라 작동 할 수 있는로드 균형 조정 프록시를 사용하는 것 입니다.

나는 당신이 추구하는 것을 제공하는 것에 가까운 3 가지 접근법을 봅니다.

  • 소스 (최종 사용자) IP 주소 에 따라 수신 연결을 3 개의 IP 주소로 정적으로 분산 시킵니다. 이런 식으로 주어진 사용자는 항상 같은 서버로 연결됩니다. 대부분의 전문 방화벽이이를 수행 할 수 있습니다. 대부분의 방화벽은 백엔드 상태 확인을 수행하지 않으므로 3 대의 서버를 스스로 고 가용성으로 만들어야 할 수도 있습니다.

  • Matt Simmons에서 이미 제안한대로 DNS를 사용하고 DNS Round Robin을 사용하십시오.

  • Windows의 내장 기능 사용 네트워크로드 균형 조정 (NLB)을 사용하십시오 . 솔직히, NLB와 준 스테이트 풀 UDP 기반 서비스에서 페일 오버 시나리오가 어떻게 진행되는지 잘 모르겠습니다. 응용 프로그램이 상태를 처리하는 방식에 따라 직접 조사해야합니다. 또한 NLB는 Windows 라이센스를 사용하여 무료로 제공하고 성숙하며 성능이 우수합니다.


내 질문을 편집했습니다
Hellfrost

6

Linux Virtual Server 는 실제 서버 클러스터에 구축 된 확장 성이 뛰어나고 가용성이 높은 서버입니다. LVS 지원 UDP 프로토콜 및 소스 해시 알고리즘 (클라이언트가 항상 동일한 실제 서버에 나타나도록하려는 경우에 사용됨)

LVM을 사용하여 DNS (rr), SIP (sh)의 균형을 맞 춥니 다.


4

흥미 롭군 내가 본 프록시 소프트웨어는 대부분 TCP 기반입니다.

저의 빈약 한 경험에서 보았던 대부분의 UDP 특정로드 밸런싱은 DNS 기반이었습니다 (예 : 시간 서버, DNS 서버 등). 여러 개의 A 레코드를 제공 할 수있는 방법이 있습니까? 이것이 작동한다면, 정상적인 DNS Round Robin은 요청의 공정한 분배 (아마도 충분히 공평 할 것입니다)를 보장하고 클라이언트 캐싱은 클라이언트 측에서 캐시 기반 플랫폼을 사용한다고 가정 할 때 충실도가 유지되도록합니다.


전혀 DNS가 없습니다.
Hellfrost

2

하드웨어 또는 소프트웨어 중 어떤 종류의로드 밸런서를 사용하여이를 수행 할 수 있으며 필요한 사항에 따라 다른로드 밸런서 중에서 선택할 수 있습니다.

레벨 3로드 밸런서 : 들어오는 IP와 사용 가능한 백엔드 IP를보고 만로드 밸런싱 할 것입니다. 이러한 종류의로드 밸런서는 같은 들어오는 IP 주소를 항상 같은 백엔드로 보내서 끈적임을 보장합니다. 동일한 IP에서 많은 클라이언트가 통신하는 경우 백엔드 중 하나 (프록시 또는 회사 게이트웨이)

레벨 7로드 밸런서 : 레벨 7로드 밸런서는 레벨 3 밸런서로 균형을 잡을뿐만 아니라 패키지의 내용도 살펴 보므로 밸런싱 정책에 더 많은 유연성을 제공합니다.

UDP를 사용한다는 점을 고려하면 두 밸런서 모두 좋은 성능을 제공해야하며 UDP의 심층 패킷 검사는 TCP보다 약간 더 제한적입니다 (프로토콜 이유로 인해).

예산에 따라 소프트웨어로드 밸런서 (예 : Linux + IPVS)를 사용하여 시작한 다음 Cisco 또는 Netapp에서 제공하는 것과 같은 하드웨어로드 밸런서를 시작할 수 있습니다.


L7 부분의 경우 -1입니다. 층이 / 레벨 7로드 밸런서는 응용 프로그램 계층에서 작동 -하지만 영업 이익은 UDP를 사용하기 때문에, 그는 평범하고 오래된 HTTP를 사용하지 않는 것, 그리고 그가 어떤 응용 프로그램이 공개되지 않은 됩니다 사용. OP가 사용중인 프로토콜에 L7로드 밸런서가 존재한다는 것을 알 수 없습니다.
Jesper M

1
난 그냥로드 밸런서에서 자신의 옵션을 주석되었고, 우리는 그가 UDP를 통해 사용 모르겠어요, 난 당신이 너무 꽉이 하나를 절단하고 생각;)
lynxman

NLB / linux와 Cisco / netapp 사이에는 KEMP로드 밸런서가 있습니다. 당신은 그것의 가상 판을 얻을 수 있습니다. 돈이 들지 않습니다. 우리는 그것을 사용하고 있으며 매우 행복합니다.
pauska

2

오픈 소스 NGINX 및 애플리케이션 제공 플랫폼 인 NGINX Plus는 이제 UDP로드 밸런싱을 지원합니다. 새로운 기능은 기존 TCP 및 HTTP 기능을 기반으로 NGINX를 더욱 광범위한 인터넷 응용 프로그램 및 장치를위한 강력하고 사용하기 쉬우 며 일관된 프런트 엔드로 만듭니다.

릴리스 nginx-1.9.13에서 사용 가능

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.