Personally I wouldn't bother with a VPN. You can limit access to a group of servers easily via security groups and not have a single point of failure. I wrote a utility to manage this. If you're bringing up a new VPC + Cassandra servers every day, you can trivially apply a set of rules to your VPC: http://rustyrazorblade.com/2014/06/an-introduction-to-roadhouse/
On Tue, Oct 6, 2015 at 10:30 AM Gene <gh5...@gmail.com> wrote: > Rather than using public IPs on the Cassandra nodes at all I would set up > a VPN. > > 1. Make sure all Cassandra nodes are on the same private network with > static IPs > 2. Set up a new micro instance with a static public IP, make sure it has a > static IP on the private network as well > 3. Install OpenVPN on the new micro instance, configure it to tunnel > traffic to that private network > 4. Configure your cassandra nodes to permit access from this instance > 5. Configure your workstation to make a VPN connection and use the static, > private IPs of the cassandra nodes for your client connectivity > > -Gene > > > On Sun, Oct 4, 2015 at 5:31 PM, Renato Perini <renato.per...@gmail.com> > wrote: > >> Jonathan, I have some difficulties in understanding what you're talking >> about. A client is a program connecting to a cassandra instance. All it >> needs to know is an IP, a keyspace and a table to operate. My client is >> nothing more than a simple textual version of a program like datastax >> devcenter. No "same dc" concepts are involved for using it. >> As for AWS, I'm not changing anything. The instances, as I said multiple >> times, don't have an elastic ip, so the public IP is dynamic. This means it >> changes automatically at every reboot. >> >> >> Il 05/10/2015 02:22, Jonathan Haddad ha scritto: >> >> If your client is in the same DC, then you shouldn't use *public* ip >> addresses. If you're using a recent version of Cassandra you can just set >> the listen_interface and rpc_interface to whatever network interface you've >> got. >> >> If you're really changing IPs when you reboot machines (I have no idea >> why you'd do this, AWS definitely doesn't work this way) then I think >> you're going to hit a whole set of other issues. >> >> >> On Sun, Oct 4, 2015 at 7:10 PM Renato Perini < <renato.per...@gmail.com> >> renato.per...@gmail.com> wrote: >> >>> Yes, the client uses the same datacenter (us-west-2). >>> Maybe I haven't explained well the situation. I'm not asking to connect >>> to nodes *without* using a static IP address, but allowing Cassandra to >>> determine the current public address at the time of connection. >>> Spark, for example, uses shell scripts for configuration, so the public >>> IP (in AWS) can be assigned using the command `curl >>> http://169.254.169.254/latest/meta-data/public-ipv4`, whatever it is at >>> the time of boot. >>> Cassandra uses a yaml file for the main configuration, so this is >>> impossibile to achieve. Basically I would like to make the client connect >>> correctly on all nodes using their public IPs without being required to >>> know them (the client would discover them dynamically while connecting). >>> >>> >>> >>> Il 05/10/2015 00:55, Jonathan Haddad ha scritto: >>> >>> So you're not running the client in the same DC as your Cassandra >>> cluster. In that case you'll need to be able to connect to the public >>> address of all the nodes. Technically you could have a whitelist and only >>> connect to 1, I wouldn't recommend it. >>> >>> This is no different than any other database in that you would need a >>> public address to be able to connect to the servers from a machine not in >>> your datacenter. How else would you connect to them if you don't provide >>> access? >>> >>> On Sun, Oct 4, 2015 at 6:35 PM Renato Perini <renato.per...@gmail.com> >>> wrote: >>> >>>> Seems to be not the case when connecting to my (single) data center >>>> using the java connector with a small client I have developed for testing. >>>> For the broadcast_rpc_address I have configured the local IP of the >>>> nodes. The cluster works fine and nodes communicates fairly well using >>>> their local IPs. When I connect to a node (let's say node 1) from the >>>> outside using the java driver and the node's public IP, the cluster >>>> discovery uses internal IPs for contacting other nodes, leading to >>>> (obviously) errors. >>>> >>>> As for AWS, Elastic IPs are free as long as they're associated to an >>>> instance and the machines are up 24h/7. I have to shut down the machines >>>> during the night for various reasons, so unfortunately they're not totally >>>> free for my use case. >>>> >>>> >>>> >>>> Il 05/10/2015 00:04, Jonathan Haddad ha scritto: >>>> >>>> Public IP? No, not required unless you're running multiple DCs. >>>> >>>> Where are you running a DC that IPs aren't cheap? If you're in AWS >>>> they're basically free (or at least the cheapest section of your bill by >>>> far) >>>> >>>> >>>> >>>> On Sun, Oct 4, 2015 at 5:59 PM Renato Perini <renato.per...@gmail.com> >>>> wrote: >>>> >>>>> Is cassandra really supposed to have a static public IP for each and >>>>> single node in the cluster? >>>>> This seems to be expensive (static IPs are nor free neither cheap), >>>>> still the broadcast_rpc_address expects a static IP for client >>>>> communications (load balancing, contact points, etc.) >>>>> Is there some mechanism to determine a public IP at runtime? >>>>> >>>>> Basically, I have nodes (machines) with dynamic public IPs and I cannot >>>>> embed them in the cassandra.yaml file because of their dynamic nature >>>>> (they change at each reboot). >>>>> Any solution to this? >>>>> >>>>> Thanks. >>>>> >>>> >>>> >>> >> >
