Have Riak servers in separate cluster behind a load balancer, or on same machines as web server?
gstein at gmail.com
Tue Oct 4 18:59:56 EDT 2011
I'm with Kyle on this one. Even better, my 'newhttp' branch on Github
enables this kind of multiple-connection and automatic fail-over.
That branch does have a basic sketch for automatic addition/removal of
Riak nodes as you manipulate your cluster. I'll need it one day, but
not "now", so I haven't finished it yet (the monitor.py background
Regarding security: it is the same for option A and B and C (you're
just shifting stuff around, but it is pretty much all the same). Put
your webservers in one security group, and the Riak nodes in another.
Open the Riak ports *only* to the webserver security group and to each
Avoiding two services on one machine (e.g web + riak) is also much
easier to manage/maintain. Just have web machines and riak machines.
On Tue, Oct 4, 2011 at 17:09, Aphyr <aphyr at aphyr.com> wrote:
> Option C: Deploy your web servers with a list of hosts to connect to. Have
> the clients fail over when a riak node goes down. Lower latency without
> sacrificing availability. If you're using protobufs, this may not be as big
> of an issue.
> On 10/04/2011 02:04 PM, O'Brien-Strain, Eamonn wrote:
>> I am contemplating two different architectures for deploying Riak nodes
>> and web servers.
>> Option A: Riak nodes are in their own cluster of dedicated machines
>> behind a load balancer. Web servers talk to the Riak nodes via the load
>> balancer. (See diagram http://eamonn.org/i/riak-arch-A.png )
>> Option B: Each web server machine also has a Riak node, and there are also
>> some Riak-only machines. Each web server only talks to its own localhost
>> Riak node. (See diagram http://eamonn.org/i/riak-arch-B.png )
>> All machines will deployed as elastic cloud instances. I will want to
>> spin up and spin down instances, particularly the web servers, as demand
>> varies. Both load balancers are non-sticky. Web servers are currently
>> talking to Riak via HTTP (though might change that to protocol buffers in
>> the future). Currently Riak is configured with the default options.
>> Here is my thinking of the comparative advantages:
>> Option A:
>> - Better for security, because can lock down the Riak load balancer to
>> only open a single port and only for connections from the web servers.
>> - Less churn for Riak of nodes entering and leaving the Riak cluster (as
>> web servers spin up and down)
>> - More flexibility in scaling storage and web tiers independently of each
>> Option B:
>> - Faster localhost connection from web server to Riak
>> I think availability is similar for the two options.
>> The web server response time is the primary metric I want to optimize.
>> Most web server requests will cause several requests to Riak.
>> What other factors should I take into account? What measurements could I
>> make to help me decide between the architectures? Are there other
>> architectures I should consider? Should I add memcached? Does anyone have
>> any experiences they could share in deploying such systems?
>> riak-users mailing list
>> riak-users at lists.basho.com
> riak-users mailing list
> riak-users at lists.basho.com
More information about the riak-users