At the risk of repeating the previous conclusions:
(a) This configuration obviates the need for a patch that I had posted earlier. This is a good thing.
(b) The reported latency(@Sasha) is less than ordinary latencies in EC2. The reasons behind this are not well understood. However I wouldn't look a gift horse in the mouth.
(c) This configuration provides cloud provider independence for those interested in such things; although YMMV in context of (b).
(d) This configuration can be run instead of the security configurations in C0.8 for certain use-cases for secure communications.
On Tue, Apr 26, 2011 at 1:20 PM, Sasha Dolgy <email@example.com>
Ok, on each node, I have configured the listen address for cassandra
as the VIP interface (tunXXX). This allows other cassandra instances
to connect ONLY through the VPN network. The listen address is not
configured for the eth0 interface (EC2).
rpc_address is set to 0.0.0.0 so that it can listen on all interfaces.
if it's left blank, it will default to the value of the listen
configuration ... which would
mean all appserver -> cassandra traffic would be routed through the
VPN connection (not what I want).
When looking at netstat, I see the following on a node:
tcp 0 0 0.0.0.0:9160 0.0.0.0:* LISTEN
tcp 0 0 172.16.1.7:7000 0.0.0.0:* LISTEN
9160 allows clients to connect to the environment to GET/PUT data
while the VPN interface is for node to node, secured, communication.
As you see, I'm not referencing the EC2 IP anywhere in the
configuration. This allows me to leverage rackspace, amazon or any
other services provider ... so long as my vpn tunnels are configured
appropriate for each endpoint / environment.
On Tue, Apr 26, 2011 at 3:55 PM, pankaj soni <firstname.lastname@example.org> wrote:
> I have a question regarding Vyatta or any providing VIP in general. While
> routing through gateway do we bind it to ec2 nodes private IP or public IP?
> Also, in general could you explain how VIP might help for I am new towards
> this side of field.