Replicar beanstalkd para alta disponibilidad


15

El título lo dice todo.

¿Alguien sabe de una manera de replicar beanstalkd de manera que si un servidor de beanstalk se cayera, otros esclavos pudieran hacerse cargo?

Este es un enfoque en el que pensé: podría hacer que beanstalk escriba su binlog (con el -b) en una ubicación compartida, y luego de alguna manera hacer que un servidor secundario / de respaldo inicie beanstalkd si falla el primario.

Sin embargo, debe haber una mejor manera.

Respuestas:


5

Como está escribiendo en el disco a través de binlog, creo que podría hacer algo similar a lo que suelen hacer los administradores de MySQL: heartbeat w / DRBD ( ejemplo aquí).

Sin embargo, la última vez que intenté usar heartbeat no era compatible con la comprobación sin multidifusión entre nodos, lo que significa que era más o menos imposible de ejecutar en la infraestructura de nube / VPS (AWS, Linode, Slicehost, etc.). De hecho, la mayoría de los servicios de clustering usan multidifusión. Puede que este ya no sea el caso, pero es algo a tener en cuenta. Es posible que pueda usar keepalived para proporcionar conmutación por error basada en IP, que también solo admite multidifusión, PERO tiene un parche disponible a través de Willy Tarreau (autor de HAProxy ) para agregar soporte de unidifusión . Personalmente lo probé en un par de servidores Linode VPS y keepalived puede realizar una conmutación por error de una dirección IP compartida en caso de que falle el servidor maestro.

Una cosa que puede hacer que probablemente sea menos óptima es escribir trabajos en varios servidores beanstalkd (también conocidos como particionamiento). Si uno de ellos falla, haga que su aplicación lo detecte y escriba a las otras instancias en su lugar. Sus trabajadores tendrán que sondear inteligentemente cada una de las instancias beanstalkd y poder ignorar las instancias muertas. Como está haciendo un binlog, volver a crear una instancia debería ser tan fácil como reiniciarlo y la aplicación / los trabajadores lo detectarán y continuarán como de costumbre (y comenzarán a procesar los trabajos en la instancia recién iniciada). Obviamente estoy simplificando el proceso, pero esa es otra forma de manejarlo.


1
Corosync admite unidifusión y es la herramienta de agrupación predeterminada en las distribuciones basadas en Redhat.
Terence Johnson

Gracias, no sabía sobre Corosync. Lo tendremos en cuenta para futuros proyectos.
andrew
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.