Using multiple network interfaces
Steps for configuring Cassandra for multiple network interfaces or when using different regions in cloud implementations.
How to configure Cassandra for multiple network interfaces or when using different regions in cloud implementations.
You must configure settings in both the cassandra.yaml file and the property file (cassandra-rackdc.properties or cassandra-topology.properties) used by the snitch.
Configuring cassandra.yaml for multiple networks or across regions in cloud implementations
In multiple networks or cross-region cloud scenarios, communication between data centers can only take place using an external IP address. The external IP address is defined in the cassandra.yaml file using the broadcast_address setting. 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 address of the node.
This allows Cassandra nodes to bind to nodes in another network or region, thus enabling multiple data-center support. For intra- network or region traffic, Cassandra 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
Note: 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 multiple networks
External communication between the datacenters can only happen when using the broadcast_address (public IP).
The GossipingPropertyFileSnitch is recommended for production. The cassandra-rackdc.properties file defines the datacenters used by this snitch.
For each node in the network, specify its datacenter in cassandra-rackdc.properties file.
In the example below, there are two cassandra datacenters and each data center 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.)
Network A | Network B |
---|---|
Node and datacenter:
|
Node and datacenter:
|
Configuring the snitch for cross-region communication in cloud implementations
In cloud 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 data center name and 1 is the rack location. (Racks are important for distributing replicas, but not for datacenter naming.)
In the example below, there are two cassandra datacenters and each data center 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.)
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.
Region: us-east | Region: us-west |
---|---|
Node and datacenter:
This results in four us-east data
centers:
|
Node and datacenter:
This results in four us-west data
centers:
|
Package installations | /etc/cassandra/cassandra.yaml |
Tarball installations | install_location/resources/cassandra/conf/cassandra.yaml |