Feeds 3
Artículos recientes
Nube de tags
seguridad
mfa
dns
zerotrust
monitorizacion
kernel
bpf
sysdig
port knocking
iptables
linux
pxe
documentación
rsyslog
zeromq
correo
dovecot
cassandra
solandra
solr
systemtap
nodejs
redis
hadoop
mapreduce
firewall
ossec
psad
tcpdump
tcpflow
Categorías
Archivo
Proyectos
Documentos
Blogs
Gestión de logs con Solandra II Fri, 05 Aug 2011
Seguimos con el segundo post de la serie, en el que pasamos a dar una descripción un poco más técnica de los componentes necesarios para poner en marcha todo lo descrito en el primero. No vamos a entrar en demasiado detalle. En todo caso, una vez conocidas las aplicaciones es más fácil buscar información en la red.
Aunque Solandra puede encargarse de la instalación de Cassandra, aquí vamos a usar los componentes por separado.
Cassandra
Cassandra es un tipo de base de datos creado siguiendo los principios propuestos por Dynamo (Amazon) y por BigTable (Google). El que quiera entrar en detalle tiene bibliografía y mucha documentación disponible.
Explicar el modelo de datos, la replicación o los niveles de consistencia va más allá del objetivo de este post. Lo más interesante en nuestro contexto es dejar claro que Cassandra es una base de datos completamente distribuida y descentralizada, en la que todas las máquinas del cluster cumplen el mismo y único rol, sin distinciones entre "maestros", "esclavos", "catálogos", .... Esto significa que añadir capacidad a un cluster de Cassandra supone básicamente añadir más hierro. Nada más.
La instalación puede complicarse todo lo que queramos, pero lo básico es:
# Cuidado con la versión cd /tmp/ && wget http://apache.rediris.es/cassandra/0.8.2/apache-cassandra-0.8.2-bin.tar.gz cd /usr/local/ && tar xvzf /tmp/apache-cassandra-0.8.2-bin.tar.gz
A partir de aquí se crean los directorios de datos y logs (por ejemplo /var/lib/cassandra y /var/log/cassandra), y se adaptan los ficheros de configuración (que están en /usr/local/apache-cassandra-0.8.2/conf). El que más nos interesa ahora es cassandra.yaml. En github hay un ejemplo de configuración de este fichero, aunque sea casi por defecto, de cada uno de los tres nodos que he usado en esta prueba.
Hay un par de opciones de configuración que pueden servir para comprender la estructura del sistema. Un cluster de Cassandra se entiende como un anillo en el que cada uno de los nodos gestiona un volumen determinado de datos (replicación aparte). Básicamente estamos hablando de una serie de claves (hashes) que se distribuyen de una forma más o menos equilibrada entre todas las máquinas. Aunque no sea estrictamente necesario, como para esta prueba he usado un número fijo de nodos (3), he asignado ya desde el comienzo un 33% de datos a cada uno. Por supuesto, en un entorno real en el que se añaden y quitan nodos dinámicamente la gestión es diferente. La configuración en mi laboratorio es la siguiente:
# Nodo 1 initial_token: 0 # Nodo 2 initial_token: 56713727820156410577229101238628035242 # Nodo 3 initial_token: 113427455640312821154458202477256070485
La otra opción que merece la pena comentar es "seed_provider". Cassandra usa un protocolo tipo Gossip para distribuir la información entre los nodos. Esto significa que, cuando se añade un nuevo miembro al cluster, es suficiente con indicarle un servidor activo del mismo. El protocolo se encarga de propagar esta nueva información en todos los nodos. Por lo tanto, la configuración se limita a especificar una (o varias) IPs activas:
seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: 192.168.10.145
Hay mucha más opciones de configuración, por supuesto, pero lo dejamos aquí.
En este momento ya se podría ejecutar Cassandra, pero esperaremos a instalar Solandra.
Solandra
Hablemos antes de lo que es Solr, una vez más, muy muy por encima.
Solr es una plataforma de búsqueda construida sobre la librería Lucene. Simplificando mucho, y en el contexto de este post, ofrece un interfaz XML (es el que nos interesa aquí, pero no el único) para añadir documentos, y un API HTTP a través de cual recibir resultados en formato JSON (entre otros).
Todo se verá más claro cuando creemos el schema para la gestión de logs. Para el que quiera profundizar más en Solr, aquí tiene un libro.
Volvamos a Solandra. La instalación es sencilla. Una vez descargado el tar.gz desde githubsolandra, y con ant y los binarios de java en el path, ejecutamos lo siguiente en cada uno de los nodos:
# El nombre del fichero cambia cd /usr/local && tar xvzf /tmp/tjake-Solandra-4f3eda9.tar.gz cd tjake-Solandra-4f3eda9/ ant -Dcassandra=/usr/local/apache-cassandra-0.8.2 cassandra-dist
Si todo va bien, en unos minutos la salida estándar mostrará lo siguiente:
.... cassandra-dist: [copy] Copying 36 files to /usr/local/apache-cassandra/lib [copy] Copying 8 files to /usr/local/apache-cassandra/conf [copy] Copying 1 file to /usr/local/apache-cassandra/bin [echo] Libraries successfully copied into cassandra distribution [echo] Start the cassandra server with /usr/local/apache-cassandra/bin/solandra command BUILD SUCCESSFUL Total time: 2 minutes 43 seconds
Durante la instalación deberían haberse copiado las librerías y scripts en el arbol de Cassandra. Incluyendo algunos ficheros de configuración, que en este caso dejamos por defecto, aunque lo normal sería que los adaptásemos.
Sin más, vamos a arrancar Solandra (y con ello Cassandra), en cada nodo. Como no hemos hecho ningún cambio en el logueo, vamos a ver todos los mensajes por la salida estándar:
cd /usr/local/apache-cassandra-0.8.2/bin/ ./solandra &
Y con esto ya debería estar todo listo. El siguiente paso es añadir el schema (parecido a como se haría en un Solr estándar), volcar los datos, y preparar el interfaz web. Pero esto es cosa de un tercer post. No pensaba escribirlo, pero bueno, este ya es demasiado largo.