Réplication de beanstalkd pour la haute disponibilité

Le titre dit tout.

Quelqu'un connaît-il un moyen de répliquer Beanstalkd de telle sorte que si un serveur Beanstalk tombe en panne, d'autres esclaves pourraient prendre le relais?

Voici une approche à laquelle j'ai pensé: je pourrais faire en sorte que beanstalk écrive son binlog (avec le -b) dans un emplacement partagé, puis faire en sorte qu'un serveur secondaire / de secours démarre beanstalkd si le principal échoue.

Il doit cependant y avoir un meilleur moyen.

Comme il écrit sur le disque via binlog, je pense que vous pourriez faire quelque chose de similaire à ce que les administrateurs MySQL font généralement: battement de coeur avec DRBD ( exemple ici).

La dernière fois que j'ai essayé d'utiliser Heartbeat, il ne supportait pas la vérification non multicast entre les nœuds, ce qui signifie qu'il était plus ou moins impossible de fonctionner sur une infrastructure cloud / VPS (AWS, Linode, Slicehost, etc.). En fait, la plupart des services de clustering utilisent la multidiffusion. Ce n'est peut-être plus le cas, mais c'est quelque chose dont il faut être conscient. Vous pouvez peut-être utiliser keepalived pour fournir un basculement basé sur IP, qui ne prend également en charge que la multidiffusion MAIS a un correctif disponible via Willy Tarreau (auteur de HAProxy ) pour ajouter un support de monodiffusion . J'ai personnellement testé cela sur une paire de serveurs Linode VPS et keepalived est capable de basculer une adresse IP partagée en cas de défaillance du serveur maître.

Une chose que vous pouvez faire qui est probablement moins optimale est d'écrire des tâches sur un certain nombre de serveurs beanstalkd (aka partitionnement). Si l'un d'eux tombe en panne, demandez à votre application de le détecter et d'écrire à la place sur les autres instances. Vos employés devront interroger intelligemment chacune des instances de beanstalkd et être capables d'ignorer les instances mortes. Étant donné que vous effectuez un binlog, la restauration d'une instance devrait être aussi simple que de la redémarrer et l'application / les travailleurs le détectera et continuera comme d'habitude (et commencera à traiter les travaux dans l'instance nouvellement démarrée). Je simplifie évidemment le processus, mais c'est une autre façon de le gérer.