About snitches

A snitch determines the datacenters and racks to which nodes belong. Snitches inform the database about the network topology, ensuring requests are routed efficiently. Snitches enable Hyper-Converged Database (HCD) to distribute replicas by grouping machines into datacenters and racks. Specifically, the replication strategy places the replicas using the information that the new snitch provides.

All nodes in a cluster must use the same snitch.

HCD strives to avoid placing more than one replica on the same rack, which is not necessarily a physical location.

If you change snitches, you may need to perform additional steps because the snitch affects where replicas are placed.

Types of snitches

Hyper-Converged Database (HCD) provides the following types of snitches:

SimpleSnitch (default)

This snitch determines proximity based on the strategy order. This can enhance cache locality when read repair is disabled. It is only suitable for single-datacenter deployments.
GossipingPropertyFileSnitch

This snitch is recommended for production.

It uses rack and datacenter information for the local node defined in the cassandra-rackdc.properties file and propagates this information to other nodes through gossip.

PropertyFileSnitch

This snitch determines proximity based on the rack and datacenter. It uses the network details located in the cassandra-topology.properties file.

When using this snitch, define datacenter names using a standard convention, and make sure that the datacenter names correlate to the names of your datacenters in the keyspace definition. Every node in the cluster should be described in the cassandra-topology.properties file, which must be exactly the same on every node in the cluster.
AlibabaCloudSnitch

A snitch for the Alibaba Cloud platform. It assumes the Alibaba Elastic Compute Service (ECS) region is a datacenter and an ECS availability zone is a rack. The format of the zone ID is cn-hangzhou-a where cn stands for China, hangzhou is the Hangzhou region, and a is the availability zone ID.
CloudstackSnitch

A snitch for the Apache Cloudstack platform that assumes a Cloudstack zone follows the typical convention country-location-availability_zone and uses the country/location tuple as a datacenter and the availability zone as a rack.
Ec2Snitch

Use this snitch for simple cluster deployments on Amazon EC2 where all nodes in the cluster are within a single region.

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. Because private IPs are used, this snitch does not work across multiple regions.
Ec2MultiRegionSnitch

Use this snitch 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.
GoogleCloudSnitch

A snitch for the Google Cloud Platform. The GCP region is treated as a datacenter, and the availability zones are treated as racks within the datacenter. All communication occurs over private IP addresses within the same logical network.
RackInferringSnitch

This snitch determines the proximity of nodes by datacenter and rack, which are assumed to correspond to the second and third octet of the node’s IP address, respectively. It is best used as an example for writing a custom snitch class (unless this format happens to match your deployment conventions).

Dynamic snitches

Dynamic snitches monitor the performance of reads from the various replicas and chooses the best replica based on this history.

By default, all snitches use a dynamic snitch layer that monitors read latency and, when possible, routes requests away from poorly-performing nodes. The dynamic snitch is enabled by default and is recommended for use in most deployments. For information on how this works, see the Dynamic snitching in Cassandra: past, present, and future blog post. Configure dynamic snitch thresholds for each node in the cassandra.yaml configuration file. Also, see the properties listed under About failure detection and recovery.

About snitches

Types of snitches

Dynamic snitches

Was this helpful?

Give Feedback