Erlang을 사용하면 클러스터간에로드를 어떻게 배포해야합니까?

Question

나는 슬레이브/풀 모듈을보고 있었고 내가 원하는 것과 비슷해 보이지만 응용 프로그램에서 단일 실패 지점이있는 것 같습니다 (마스터 노드가 줄어드는 경우).

클라이언트는 연결을 허용하는 게이트웨이 목록 (폴백을 위해 - 모두 같은 일을합니다)을 가지고 있으며, 하나는 클라이언트에 의해 무작위로 선택됩니다. 클라이언트가 연결되면 모든 노드를 검사하여로드가 가장 적은 다음 가장 적게로드 된 서버의 IP가 클라이언트로 다시 전달됩니다. 그런 다음 클라이언트는이 서버에 연결하고 모든 것이 실행됩니다.

요약하면 모든 노드가 게이트웨이로 작용하고 실제로 클라이언트 요청을 처리하기를 원합니다. 로드 밸런싱은 클라이언트가 처음에 연결할 때만 수행됩니다. 모든 실제 패킷이 모든 실제 패킷을 사용하고 클라이언트의 "홈"노드에서 처리됩니다.

어떻게할까요?

Answer 1

이 모듈이 아직 구현되어 있는지 모르겠지만 내가 말할 수있는 것은로드 균형이 과대 평가되었습니다. 내가 논쟁 할 수있는 것은, 임의의 작업 배치는 미래에 부하가 어떻게 올지, 대부분의 경우에 실제로하지 않는 대부분의 정보를 더 많이 알지 않는 한 가장 좋은 방법입니다. 당신이 쓴 것 :

클라이언트가 연결되면 모든 노드를 검사하여로드가 가장 적은 다음 가장 적게로드 된 서버의 IP가 클라이언트로 다시 전달됩니다.

다음 MS에서 가장 적게로드 된 노드가 가장 높지 않다는 것을 어떻게 알 수 있습니까? 목록에 포함하지 않을 높은로드 된 노드가 다음 MS에서만로드를 떨어 뜨리지 않을 것임을 어떻게 알 수 있습니까? 당신은 매우 드문 경우가 없다면 실제로 그것을 알 수 없습니다.

노드의 성능을 측정 (또는 계산)하고 노드의 확률을 설정하십시오. 현재로드에 관계없이 무작위로 노드를 선택하십시오. 이것을 초기 접근 방식으로 사용하십시오. 설정하면 더 정교한 알고리즘을 구성 할 수 있습니다. 나는이 초기 접근법을이기는 것이 매우 어려울 것이라고 확신합니다. 나를 믿으세요.

편집하다: 미묘한 세부 사항으로 더 명확하게하기 위해, 나는 당신이 현재와 역사적 부하에서 미래 부하를 예측할 수 없다고 강력하게 주장하지만, 작업 시간 확률과 작업 수명의 현재 분해에 대한 지식을 사용해야합니다. 이 작업은 달성하기가 너무 어렵습니다.

Answer 2

감독 트리의 목적은 프로세스를 반드시 전달하는 요청을 관리하는 것입니다. 다른 코드를 사용하여 사용 가능한 프로세스 목록의 구성원에게 직접 요청을 보낼 수없는 이유는 없습니다. 수영장을 참조하십시오 : get_nodes 또는 pool : get_node () 함수는 해당 목록을 얻는 한 가지 방법을 참조하십시오.

풀 모듈이 프로세스 관리 (재시작, 모니터링 및 킬링 처리)를 처리하고 다른 모듈을 사용하여 프로세스 풀에 요청을 투명하게 리디렉션 할 수 있습니다. 그래도 분산 수영장을 찾고 있었을까요? 분산 노드로가는 Erlang의 마스터 프로세스에서 벗어나기가 어려울 것입니다. 전체 실행 시스템은 거의 하나의 큰 감독 트리입니다.

Answer 3

최근에 프로세스 그룹을 설정할 수있는 PG 모듈을 기억했습니다. 그룹으로 전송 된 메시지는 그룹의 모든 프로세스로 이동합니다. 당신이 원하는 것을 향한 부분을 얻을 수 있습니다. 실제 요청을 처리하는 프로세스를 결정하려면 코드를 작성해야하지만 마스터가 사용하지 않고 풀을 얻을 수 있습니다.