Soplones en Cassandra

En este artículo, analizaremos el Snitch y sus tipos, y Comprender cómo configurar los archivos cassandra-topology.properties y cassandra-rackdc.properties ayuda a configurar centros de datos y clústeres. 

Snitches: 
En Cassandra Snitch es muy útil y snitch también ayuda a mantener un registro para evitar almacenar múltiples réplicas de datos en el mismo rack. En Cassandra, son aspectos muy importantes para evitar múltiples réplicas. En la estrategia de replicación, asignamos el número de réplicas y también definimos el centro de datos. Esta información es muy útil para que el soplón identifique el Node y a qué rack pertenece. 

En Cassandra , el trabajo del soplón es determinar qué centros de datos y bastidores debe usar para leer y escribir datos. En Cassandra, todos los soplones son dinámicos por defecto. 

Tipos de soplones: 
 

1. SimpleSnitch: 
   en Cassandra, es un soplón predeterminado y bueno para entornos de desarrollo. No reconoce los centros de datos o los bastidores y tampoco busca el archivo Cassandra-topologies.properties y, por lo tanto, no se puede utilizar para entornos de varios centros de datos. 
    
2. GossipingPropertyFileSnitch: 
   En Cassandra, es muy importante que datastax también recomiende archivos para uso en producción. Este soplón también busca el archivo Cassandra-topologies.properties para identificar la información del clúster, de modo que el centro de datos y el rack pertenecen, luego configuramos en el archivo cassandra-rackdc.properties para el resto de los Nodes usando chismes. 

   Podemos configurar GossipingPropertyFileSnitch editando el archivo Cassandra-topologies.properties. 
   Echemos un vistazo.

dc=DC1
rack=RACK1
prefer_local=true 

1. Aquí, estamos usando dc y rack, que se refiere al centro de datos y al rack, y prefer_local=true se refiere a la comunicación con la dirección IP local mientras no se comunica en varios centros de datos para limitar el uso del ancho de banda de la red. 
    
2. Ec2Snitch: 
   es un chivato importante para las implementaciones y es un chivato simple para las implementaciones de Amazon EC2 donde todos los Nodes están en una sola región. En Ec2Snitch, el nombre de la región se refiere al centro de datos y la zona de disponibilidad se refiere al bastidor en un clúster. 

    

3. Ec2MultiRegionSnitch: 
   en Cassandra, usamos este snitch cuando los clústeres abarcan varias regiones y Ec2MultiRegionSnitch para clústeres basados ​​en Amazon EC2. 

    

4. GoogleCloudSnitch: 
   en Cassandra, es el soplón para una implementación de Cassandra en Google Cloud Platform (GCP) en una o varias regiones. Es el soplón que admite GCP (Google Cloud Platform). 

    

5. RackInferringSnitch: 
   En este snitch averiguamos la ubicación por rack y centro de datos. En este soplón, el tercer y cuarto octeto de la dirección IP, por ejemplo, 10.40.08.230, corresponde al bastidor y al centro de datos. Este es un chivato muy útil para escribir clases de chivato personalizadas. 

    

6. PropertyFileSnitch: 
   Este snitch usa el archivo cassandra-topology.properties y debemos definir la información de los Nodes por la cual podemos Determinar la cercanía de los Nodes. 
   Podemos identificar la información de los Nodes según el centro de datos y el rack al que pertenecen. Para determinar la cercanía de los Nodes, PropertyFileSnitch utilizó las definiciones de red del archivo cassandra-topology.properties. 

    

7. CloudstackSnitch: 
   es el soplón que se basa en la nube y es un soplón para un clúster basado en Apache Cloudstack. 

    

Ahora, comprendamos los archivos cassandra-topology.properties y cassandra-rackdc.properties. 

Descripción de los archivos cassandra-topology.properties y cassandra-rackdc.properties: 

Contiene la topología de todo el clúster y la información de los archivos cassandra-topology.properties y cassandra-rackdc.properties. 
Tomemos un ejemplo. 
 

dc = DC1
rack = RAC1 
rack= RAC2

En el siguiente ejemplo, DC1 y DC2 son dos centros de datos físicos y hay dos bastidores para cada uno de ellos. En Cassandra, PropertyFileSnitch usa el archivo de propiedades que es el archivo cassandra-topologies.properties para identificar el Node del clúster. Si no identificamos los Nodes del clúster en el archivo cassandra-topologies.properties, la base de datos asume que los datos están en el centro de datos y el bastidor predeterminados. 
 

# datacenter One
10.40.08.230  = DC1:RAC1
10.30.11.231  = DC1:RAC1
10.54.06.232  = DC1:RAC1

130.40.20.106  = DC1:RAC2
130.41.21.229  = DC1:RAC2
130.42.29.111  = DC1:RAC2

# datacenter Two

100.46.12.120  = DC2:RAC1
100.60.13.201  = DC2:RAC1
100.24.35.184  = DC2:RAC1

30.22.20.110  = DC2:RAC2
30.35.21.210  = DC2:RAC2
30.27.20.231  = DC2:RAC2 

Es muy importante actualizar el archivo Cassandra-topologies.properties mientras vamos a agregar o eliminar Nodes del clúster y luego para saber a qué centro de datos y rack pertenecen los Nodes. desde la perspectiva del rendimiento, es muy importante mantener un registro de esa información para Cassandra. 

Aquí, vamos a describir el archivo cassandra-rackdc.properties: En el ejemplo anterior, estamos usando la siguiente información de node. 
Echemos un vistazo. 
 

dc=DC1
rack=RAC1 

Nota: 
Existen los siguientes tipos de soplón que buscan en el archivo cassandra-rackdc.properties para identificar la información del clúster de Nodes, como a qué centro de datos y qué bastidor pertenecen. 
Echemos un vistazo. 
 

GossipingPropertyFileSnitch
Ec2Snitch
Ec2MultiRegionSnitch