0

I'm migrating my application from Riak 1.4 to Riak 2.

In the past I have been colocating my application on every node of the Riak cluster. It connects only to the local Riak node (at localhost:8087), monitors the availability of Riak and advertises its own availability based on that. Remote Haproxies monitor multiple of these applications and direct enduser traffic to any available application instance:

enduser --network--> Haproxy --network--> pool[ application->riak ]

My reasons for this architecture were

  • Lowest possible latency between application and Riak
  • Zero-Conf of the application, it always expects Riak at localhost
  • Good control of traffic distribution in HAProxy (and only there)
  • Good security: protobuf was only exposed to localhost

The java-client documentation now suggests that, when connecting, a Riak client application shall be aware of all nodes of a Riak cluster. In light of this, is my approach still acceptable? Or should I instead switch to a scenario where every instance of the application is aware of, and connected to, every Riak node?

Hank
  • 4,597
  • 5
  • 42
  • 84

1 Answers1

2

I believe there are a couple of purposes for the client to be aware of every node

  • application nodes are still available when a single Riak node goes down
  • a single overloaded application node does not transfer all of its load to a single Riak node
  • there is a performance gain (noted in the Dynamo white paper) to submitting writes directly to a primary node instead of submitting to a random node that must then forward the request

It looks like, in your situation, you already have haproxy dealing with individual application node availability and load balancing, and you are already not taking advantage of the performance difference.

Maintaining a pool of connections in the client is not new, I believe it is already available in the 1.4 client. If you didn't need it before, adding it now would make sense if you also plan to make other changes that would take advantage of the benefits of a connection pool.

Joe
  • 25,000
  • 3
  • 22
  • 44