고 가용성을 위해 Beanstalk 복제

제목은 모든 것을 말합니다.

Beantalk 서버가 다운되면 다른 슬레이브가 대신 할 수 있도록 Beantalkd를 복제하는 방법을 아는 사람이 있습니까?

내가 생각한 한 가지 접근법은 다음과 같습니다. Beanstalk가 binlog (-b를 사용하여)의 binlog를 공유 위치에 쓰도록 한 다음 기본 서버가 실패하면 보조 / 백업 서버가 Beantalk를 시작하도록 할 수 있습니다.

그래도 더 좋은 방법이 있어야합니다.

:이 바이너리 로그를 통해 디스크에 쓰기 때문에, 나는 당신이 MySQL이 일반적으로 어떻게 관리자 것과 비슷한 할 수 있다고 생각 것 하트 비트를 승 / DRBD ( 예를 들어 여기 참조).

마지막으로 하트 비트를 사용하려고 시도했을 때 노드 간 비 멀티 캐스트 검사를 지원하지 않았으므로 클라우드 / VPS 인프라 (AWS, Linode, Slicehost 등)에서 실행하는 것이 다소 불가능했습니다. 실제로 대부분의 클러스터링 서비스는 멀티 캐스트를 사용합니다. 더 이상 그렇지 않을 수도 있지만 알고 있어야합니다. 당신은 사용할 수 있습니다 keepalived 멀티 캐스트 지원하지만 윌리 Tarreau (의 저자를 통해 사용할 수있는 패치가도 만 제공하는 IP 기반의 페일 오버, HAProxy 하는) 유니 캐스트 지원을 추가를 . 필자는 한 쌍의 Linode VPS 서버에서이를 직접 테스트했으며 keepalived는 마스터 서버 장애시 공유 IP 주소를 페일 오버 할 수 있습니다.

최적이 아닌 방법 중 하나는 여러 Beantalked 서버 (일명 파티셔닝)에 작업을 작성하는 것입니다. 둘 중 하나가 다운되면 앱에서이를 감지하여 다른 인스턴스에 쓰도록합니다. 작업자는 각 Beantalked 인스턴스를 지능적으로 폴링하고 죽은 인스턴스를 무시할 수 있어야합니다. Binlogging하기 때문에 인스턴스를 다시 시작하는 것만 큼 인스턴스를 쉽게 백업 할 수 있어야하며 앱 / 작업자는이를 감지하고 평상시처럼 계속 진행합니다 (새로 시작된 인스턴스에서 작업 처리 시작). 분명히 프로세스를 단순화하고 있지만 처리하는 또 다른 방법입니다.