[one-users] Sunstone redundant memcached setup

[Javier Fontan]

Hi Thibault,

Have you released the patch to use redis instead of memcached? It can be a
addition for a guide on Sunstone.

Cheers


On Thu, Nov 14, 2013 at 12:10 PM, Thibault Galko <thibault.galko at bosstek.net
> wrote:

>    Hi,
>
> Memcached does not support redundancy at server side, and Rack::Memcached
> does not support it either as PHP memcached client does.
>
> I've implemented a patch to use Redis as replacement for memcached Session
> using Rack:Redis in order to setup a true session failover with Redis
> Replication in a Front-End Cluster.
>
> We plan to release it to the community, but you could contact me if you
> need it asap.
>
> Best Regards,
>
> Sorry for my english ..
>
> --
>
> Thibault GALKO
>    [image: BOSSTEK.FR] <http://www.bosstek.fr>
> +33 (0)1 40 93 58 63
>  thibault.galko at bosstek.fr
>
> BOSSTEK - 150, Avenue de Verdun - 92320 Châtillon
>
>
>
>
>
> 2013/11/14 Javier Fontan <jfontan at opennebula.org>
>
>> I've been checking the API of Rack sessions put I don't find a way to
>> do what you are proposing. I'll come back to this after I finish with
>> some bugs I have in my backlog.
>>
>> On Wed, Nov 13, 2013 at 10:33 AM, Stefan Kooman <stefan at bit.nl> wrote:
>> > Hi List,
>> >
>> > If you have a setup consisting of more than one "front-end" server I
>> > think it would make sense to be able to specify more than one memcached
>> > server in sunstone. If for one reason or another a memcached server is
>> > not available anymore it can automatically try the next one configured
>> > (after $timeout value). Building this funtionality directly into
>> > sunstone gives you the benefit of "redundant" memcached servers without
>> > the need for cluster software taking care of this. If you let sunstone
>> > server A point to memcached server A (primary) and memached server B
>> > (secondary) and sunstone server B point to memcached server B (primary)
>> > and memcached server A (secondary) you've doubled the available
>> > memcached capacity during normal operations.
>> >
>> > Are there any reasons _not_ to use two different (active) memcached
>> > servers?
>> >
>> > Cheers,
>> >
>> > Stefan
>> >
>> >
>> > --
>> > | BIT BV  http://www.bit.nl/        Kamer van Koophandel 09090351
>> > | GPG: 0xD14839C6                   +31 318 648 688 / info at bit.nl
>> >
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.10 (GNU/Linux)
>> >
>> > iF4EAREIAAYFAlKDR2AACgkQTyGgYdFIOcbOYgEAwR7aRoaPgUh8n+Wa9xjAoZrH
>> > mI9eGkdoq2mmOwalR74A/jtSqnUu3L9G6I8HbXsFcMUzk9jORtUb/1NcDsIjd6Pt
>> > =uirV
>> > -----END PGP SIGNATURE-----
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opennebula.org
>> > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>> >
>>
>>
>>
>> --
>> Javier Fontán Muiños
>> Developer
>> OpenNebula - The Open Source Toolkit for Data Center Virtualization
>> www.OpenNebula.org | @OpenNebula | github.com/jfontan
>> _______________________________________________
>> Users mailing list
>> Users at lists.opennebula.org
>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>


-- 
Javier Fontán Muiños
Developer
OpenNebula - The Open Source Toolkit for Data Center Virtualization
www.OpenNebula.org | @OpenNebula | github.com/jfontan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20131219/4916479d/attachment.htm>