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 datacenters 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:

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:

CAUTION: Be sure to enable encryption and authentication when using public
IPs. See Node-to-node encryption. Another option is to use a custom
VPN to have local, inter-region/ datacenter IPs.

Additional cassandra.yaml configuration for non-EC2 implementations

If multiple network interfaces are used in a non-EC2 implementation, enable the
listen_on_broadcast_address
option.

listen_on_broadcast_address: true

In non-EC2
environments, the public address to private address routing is not automatically
enabled. Enabling listen_on_broadcast_address allows Cassandra to
listen on both listen_address and
broadcast_address with two network interfaces.

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. Enable the option prefer_local to ensure that
traffic to broadcast_address will re-route to
listen_address.

In the example below, there are two cassandra 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.)

Network A

Network B

Node and datacenter:

node0

dc=DC_A_cassandrarack=RAC1

node1

dc=DC_A_cassandrarack=RAC1

node2

dc=DC_B_cassandrarack=RAC1

node3

dc=DC_B_cassandrarack=RAC1

node4

dc=DC_A_analyticsrack=RAC1

node5

dc=DC_A_searchrack=RAC1

Node and datacenter:

node0

dc=DC_A_cassandrarack=RAC1

node1

dc=DC_A_cassandrarack=RAC1

node2

dc=DC_B_cassandrarack=RAC1

node3

dc=DC_B_cassandrarack=RAC1

node4

dc=DC_A_analyticsrack=RAC1

node5

dc=DC_A_searchrack=RAC1

Configuring the snitch for cross-region communication in cloud
implementations

Note: Be sure to use the appropriate snitch for
your implementation. If deploying on Amazon EC2, see the instructions in Ec2MultiRegionSnitch.

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 datacenter 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 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.)

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.