Configuring Amazon EC2 multi-region snitch

Use the Ec2MultiRegionSnitch for deployments on Amazon EC2 where the cluster spans multiple regions.

You must configure settings in both the cassandra.yaml file and the property file (cassandra-rackdc.properties) used by the Ec2MultiRegionSnitch.

Configuring cassandra.yaml for cross-region communication

The Ec2MultiRegionSnitch uses public IP designated in the broadcast_address to allow cross-region connectivity. Configure each node as follows:

In the cassandra.yaml, set the listen_address to the private IP address of the node, and the broadcast_address to the public IP address of the node.

This allows DataStax Enterprise nodes in one EC2 region to bind to nodes in another region, thus enabling multiple datacenter support. For intra-region traffic, DataStax Enterprise switches to the private IP after establishing a connection.
Set the addresses of the seed nodes in the cassandra.yaml file to that of the public IP. Private IP are not routable between networks. For example:
```
seeds: 50.34.16.33, 60.247.70.52
```
To find the public IP address, from each of the seed nodes in EC2:
```
curl http://instance-data/latest/meta-data/public-ipv4
```
Do not make all nodes seeds, see Internode communications (gossip).
Be sure that the storage_port or ssl_storage_port is open on the public IP firewall.

Configuring the snitch for cross-region communication

In EC2 deployments, the region name is treated as the datacenter name and availability zones are treated as racks within a datacenter. For example, if a node is in the us-east-1 region, us-east is the datacenter name and 1 is the rack location. (Racks are important for distributing replicas, but not for datacenter naming.)

For each node, specify its datacenter in the cassandra-rackdc.properties. The dc_suffix option defines the datacenters used by the snitch. Any other lines are ignored.

In the example below, there are two DataStax Enterprise datacenters and each datacenter is named for its workload. The datacenter naming convention in this example is based on the workload. You can use other conventions, such as DC1, DC2 or 100, 200. (datacenter names are case-sensitive.)

Region: us-east Region: us-west

Region: us-east	Region: us-west
Node and datacenter: node0 `dc_suffix=_1_transactional` node1 `dc_suffix=_1_transactional` node2 `dc_suffix=_2_transactional` node3 `dc_suffix=_2_transactional` node4 `dc_suffix=_1_analytics` node5 `dc_suffix=_1_search` This results in four us-east datacenters: `us-east_1_transactional us-east_2_transactional us-east_1_analytics us-east_1_search`	Node and datacenter: node0 `dc_suffix=_1_transactional` node1 `dc_suffix=_1_transactional` node2 `dc_suffix=_2_transactional` node3 `dc_suffix=_2_transactional` node4 `dc_suffix=_1_analytics` node5 `dc_suffix=_1_search` This results in four us-west datacenters: `us-west_1_transactional us-west_2_transactional us-west_1_analytics us-west_1_search`

Node and datacenter:

node0

dc_suffix=_1_transactional
node1

dc_suffix=_1_transactional
node2

dc_suffix=_2_transactional
node3

dc_suffix=_2_transactional
node4

dc_suffix=_1_analytics
node5

dc_suffix=_1_search

This results in four us-east datacenters:

us-east_1_transactional
us-east_2_transactional
us-east_1_analytics
us-east_1_search

Node and datacenter:

node0

dc_suffix=_1_transactional
node1

dc_suffix=_1_transactional
node2

dc_suffix=_2_transactional
node3

dc_suffix=_2_transactional
node4

dc_suffix=_1_analytics
node5

dc_suffix=_1_search

This results in four us-west datacenters:

us-west_1_transactional
us-west_2_transactional
us-west_1_analytics
us-west_1_search

Keyspace strategy options

When defining your keyspace strategy options, use the EC2 region name, such as us-east, as your datacenter name.

Configuring Amazon EC2 multi-region snitch

Configuring cassandra.yaml for cross-region communication

Configuring the snitch for cross-region communication

Keyspace strategy options

Was this helpful?

Give Feedback