Cluster Cassandra con dos servidores

De ChuWiki
Saltar a: navegación, buscar

Una vez instalado cassandra vamos a ver como montar un pequeño cluster con dos servidores. Evidentemente, necesitamos dos servidores que se vean en red con Apache Cassandra instalado.


Fichero de configuración

El fichero de configuración que debemos tocar está donde hayamos instalado Apache Cassandra, en conf/cassandra.yaml . Lo editamos en ambos servidores y lo que hay que tocar son los siguientes parámetros

cluster_name

Buscamos la línea con el cluster_name. Aquí únicamente debemos verificar que ambos servidores contienen el mismo nombre de cluster, por defecto es

cluster_name: 'Test Cluster'

Es importante tener en cuenta que Apache Cassandra, cuando arranca por primera vez, guarda este nombre en su base de datos interna. Si cambiamos el nombre en el fichero y rearrancamos Apache Cassandra, dará un error y no arrancará. Así que debemos elegir y cambiar este nombre en el fichero antes de arrancar Cassandra por primera vez, o bien tenemos que modificar luego también la base de datos interna. Para modificar esta base de datos interna, hay dos opciones:

  • Eliminar completamente los ficheros de base de datos (por defecto en /var/lib/cassandra/data, como podemos ver si buscamos en el mismo fichero conf/cassandra.yaml). Esta opción es un poco "brusca", puesto que perderemos también todos nuestros datos almacenados.
data_file_directories:
   - /var/lib/cassandra/data
  • Una opción más suave que parece funcionar, aunque no estoy seguro que no tenga efectos secundarios, es borrar el directorio /var/lib/cassandra/data/system/local. En este directorio se guarda la Column Familiy (tabla) que contiene el cluster_name. Cassandra vuelve a recrearla en el arrranque con el contenido del fichero conf/cassandra.yaml.
  • Entrar con un cliente de Apache Cassandra (CLI o CQL) y modificar el valor de este nombre. Por ejemplo, entrando con un cliente CLI, la siguiente secuencia de comandos muestra el nombre del cluster
use system;
get local['local']['cluster_name'] as ascii;
=> (name=cluster_name, value=Test Cluster, timestamp=1372664730870000)

En princpio bastaría cambiar ese nombre con un comando set, cambiarlo también en el fichero de configuración conf/cassandra.yaml y rearracnar cassandra. Sin embargo, en la versión de cassandra 1.2.6 hay que realizar todo este proceso ...

cambiar el contenido en la tabla correspondiente

set local['local']['cluster_name']=utf8('nuevo nombre');

parar cassandra y rearrancarlo sin cambiar el cluster_name en conf/cassandra.yaml. Esto, de alguna forma, arranca con el antiguo nombre, pero valida el nuevo. Ahora sí, cambiar el nombre dentro de conf/cassandra.yaml y rearrancar cassandra por segunda vez.

num_tokens

Buscar la línea

# num_tokens: 256

que está comentada y quitar el # del principio para descomentarla. num_tokens es un número entre 1 y 256 y de alguna forma es el peso de este servidor a la hora de repartir datos. Cuanto mayor sea el número, más datos recibirá. Lo adecuado es que los servidores más lentos, con menos disco o peor enlace de red tengan números más bajos.

seeds

Buscar el siguiente conjunto de líneas

seed_provider:
    # Addresses of hosts that are deemed contact points. 
    # Cassandra nodes use this list of hosts to find each other and learn
    # the topology of the ring.  You must change this if you are running
    # multiple nodes!
    - class_name: org.apache.cassandra.locator.SimpleSeedProvider
      parameters:
          # seeds is actually a comma-delimited list of addresses.
          # Ex: "<ip1>,<ip2>,<ip3>"
          - seeds: "127.0.0.1"

seeds indica las IPs de los servidores, por defecto sólo la del host local. Hay que cambiar la IPs de seeds por una lista de IPs separadas por comas de todos los servidores, incluido el nuestro, con su IP real, no vale 127.0.0.1. Por ejemplo

- seeds : "172.30.210.18,172.30.160.107"

endpoint_snitch

Buscar la línea

endpoint_snitch: SimpleSnitch

Aquí se indica la lógica para el reparto de datos entre los nodos de acuerdo a proximidad de IPs y otros criterios. SimpleSnitch vale para un único servidor trabajando solo. En un cluster de varios servidores podemos poner lo siguiente

endpoint_snitch: RackInferringSnitch 

listen_address

Buscar la línea

listen_address: localhost

Este línea hace que sólo se atiendan conexiones de localhost. Como queremos que atienda conexiones también de otros servidores, debemos poner la IP real de nuestro servidor, por ejemplo

listen_adrress :  172.30.210.18

rpc_address

Buscar la línea

rpc_address: localhost

esta indica que los clientes sólo pueden conectarse desde localhost. Conviene cambiarla por la IP real del servidor para permitir que las aplicaciones externas que usen la base de datos sean capaces de conectarse. Por ejemplo

rpc_address: 172.30.210.18


Ver nodos colaborando

Con esto debería estar listo. Rearrancando todos los servidores cassandra y luego ejecutando en alguno de ellos en el directorio bin de cassandra

nodetool.bat ring

deberíamos ver todos los servidores que han entrado. Un detalle a tener en cuenta es el num_tokens que descomentamos más arriba. Si hemos puesto 256, veremos con nodetool.bat ring como 256 servidores por cada servidor real.