Instalar Apache Cassandra en CentOS 8

Diagrama de nodos de Apache Cassandra en clúster

Apache Cassandra es un sistema de gestión de bases de datos NoSQL de alto rendimiento y código abierto sin un único punto de fallo. Cassandra usa un modelo de clúster en lugar del modelo de tablas típico de MySQL/PostgreSQL. Es adecuada para aplicaciones que no pueden permitirse perder datos: los datos se replican automáticamente en varios nodos para tolerancia a fallos y los nodos fallidos pueden reemplazarse sin tiempo de inactividad.

Esta guía detalla la instalación en CentOS 8 y añade prácticas y comprobaciones útiles para entornos de prueba y orientaciones para producción.

Requisitos

Un servidor con CentOS 8 y al menos 2 GB de RAM.
Contraseña de root configurada.
Acceso a Internet para descargar paquetes y repositorios.

Empezando

Antes de comenzar, actualice el servidor a la versión estable más reciente:

dnf update

Reinicie el servidor si es necesario para aplicar actualizaciones.

Instalar Java

Apache Cassandra requiere OpenJDK 8 y Python2 en esta guía (la versión de Python puede variar según el paquete). Instale OpenJDK 8 y Python2:

dnf install java-1.8.0-openjdk-devel python2

Verifique la versión de Java:

java -version

Debería ver una salida similar a la siguiente:

openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-b09)
OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)

Si la versión difiere, confirme que es compatible con la versión de Cassandra que va a instalar.

Instalar Apache Cassandra

Por defecto, Cassandra no está disponible en los repositorios estándar de CentOS 8. Cree el repositorio:

nano /etc/yum.repos.d/cassandra.repo

Añada estas líneas:

[cassandra]
name = DataStax Repo for Apache Cassandra
baseurl = http://rpm.datastax.com/community
enabled = 1
gpgcheck = 0

Guarde y cierre el archivo. Instale Cassandra (paquete dsc20 según este repositorio):

dnf install dsc20

Crear una unidad systemd para Cassandra

Algunos paquetes no generan un archivo de servicio systemd. Cree uno para gestionar el servicio:

nano /etc/systemd/system/cassandra.service

Ejemplo de archivo de servicio recomendado:

[Unit]
Description=Apache Cassandra
After=network.target

[Service]
PIDFile=/var/run/cassandra/cassandra.pid
User=cassandra
Group=cassandra
ExecStart=/usr/sbin/cassandra -f -p /var/run/cassandra/cassandra.pid
Restart=always

[Install]
WantedBy=multi-user.target

Luego recargue systemd y active el servicio:

systemctl daemon-reload
systemctl start cassandra
systemctl enable cassandra
systemctl status cassandra

Debería ver una salida parecida a la siguiente (resumen de ejemplo):

? cassandra.service - Apache
   Loaded: loaded (/etc/systemd/system/cassandra.service; disabled; vendor preset: disabled)
   Active: active (running) since Sat 2019-12-07 01:25:26 EST; 1min 51s ago
 Main PID: 1888 (java)
    Tasks: 53 (limit: 25044)
   Memory: 272.7M
   CGroup: /system.slice/cassandra.service
           ??1888 java -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities -XX:Threa>

Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,054 Writing Memtable-local@1642973315(10104/101040 serialized/live bytes, 259 ops)
Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,118 Completed flushing /var/lib/cassandra/data/system/local/system-local-jb-4-Data.db >
Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,124 Compacting [SSTableReader(path='/var/lib/cassandra/data/system/local/system-local->
Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,169 Node localhost/127.0.0.1 state jump to normal
Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,294 Compacted 4 sstables to [/var/lib/cassandra/data/system/local/system-local-jb-5,].>
Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,322 Starting listening for CQL clients on localhost/127.0.0.1:9042...
Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,376 Using TFramedTransport with a max frame size of 15728640 bytes.
Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,378 Binding thrift service to localhost/127.0.0.1:9160
Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,391 Using synchronous/threadpool thrift server on localhost : 9160
Dec 07 01:25:29 centos8 cassandra[1888]:  INFO 01:25:29,422 Listening for thrift clients...

Probar la instalación

Verifique el estado del nodo:

nodetool status

Salida de ejemplo:

Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens  Owns (effective)  Host ID                               Rack
UN  127.0.0.1  46.11 KB   256     100.0%            2a680007-8c30-4bde-9a3f-9fa212b96d11  rack1

Configurar Apache Cassandra

Por defecto Cassandra acepta conexiones solo desde localhost. Para acceder al shell CQL:

cqlsh

Salida de ejemplo:

Connected to Test Cluster at localhost:9160.
[cqlsh 4.1.1 | Cassandra 2.0.17 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
Use HELP for help.
cqlsh>

Cambiar el nombre del clúster (ejemplo):

Acceda a cqlsh:

cqlsh

En el prompt de CQL:

cqlsh> UPDATE system.local SET cluster_name = 'HowtoForge Cluster' WHERE KEY = 'local';
cqlsh> exit;

Edite el archivo de configuración para persistir el cambio:

nano /etc/cassandra/default.conf/cassandra.yaml

Cambie la línea correspondiente:

cluster_name: 'HowtoForge Cluster'

Aplique cambios:

nodetool flush system
systemctl restart cassandra

Al volver a entrar en cqlsh verá el nuevo nombre:

Connected to HowtoForge Cluster at localhost:9160.
[cqlsh 4.1.1 | Cassandra 2.0.17 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
Use HELP for help.
cqlsh>

Consideraciones importantes

Abra los puertos necesarios en el cortafuegos (por ejemplo 9042 para CQL y 9160 para Thrift si lo usa).
Revise SELinux y políticas de seguridad: podrían bloquear accesos hasta ajustarlos.
Python2 es una dependencia histórica en algunos paquetes; verifique las dependencias del paquete que instale.
En producción, no use un solo nodo; planifique varios nodos, réplicas y copias de seguridad.

Cuándo no usar Cassandra (contrajemplos)

Cuando necesita transacciones ACID fuertes y relaciones complejas: un RDBMS suele ser mejor.
Para cargas pequeñas y datos fuertemente estructurados con pocas lecturas/actualizaciones: una base de datos relacional puede ser más eficiente.
Si su equipo no tiene experiencia con operaciones de bases de datos distribuidas y tolerancia a fallos.

Alternativas y enfoques distintos

Usar contenedores: desplegar Cassandra en Docker o Kubernetes para entornos de prueba.
ScyllaDB: alternativa de alto rendimiento compatible con el protocolo de Cassandra.
Servicios gestionados: Amazon Keyspaces, Azure Managed Instance for Apache Cassandra.

Mini-metodología para despliegue en producción

Planificar topología: número de datacenters, racks y nodos por rack.
Elegir estrategia de replicación (SimpleStrategy vs NetworkTopologyStrategy).
Definir factor de replicación por datacenter.
Configurar nodos seed y tokens iniciales.
Probar en staging con carga representativa.
Establecer monitorización (latencia, SLI/SLO), backups y procedimientos de restauración.

Lista de verificación por rol

Administrador:

Confirmar requisitos de hardware y Java.
Configurar usuarios y permisos del sistema.
Establecer copias de seguridad periódicas.

DevOps:

Automatizar despliegue (Ansible, Terraform, Helm).
Configurar monitorización y alertas.
Gestionar escalado y balanceo de nodos.

Desarrollador:

Usar CQL para diseñar tablas pensando en consultas (modelado por acceso).
Probar tolerancia a fallos en entornos controlados.
Evitar operaciones que afecten a todo el clúster (reparaciones masivas sin control).

Runbook de incidentes básico

Comprobar servicio systemd:

systemctl status cassandra
journalctl -u cassandra --since "1 hour ago"

Revisar estado del clúster:

nodetool status
nodetool info
nodetool ring

Si un nodo está Down: revisar logs en /var/log/cassandra/ y reiniciar el servicio:
```
systemctl restart cassandra
```
Forzar re-sincronización o reemplazar nodo según el caso:

Usar nodetool repair y nodetool cleanup cuando sea apropiado.
Si reemplaza un nodo, seguir el procedimiento oficial para bootstrap o substituir el nodo.

Pruebas y criterios de aceptación

El servicio debe estar activo: systemctl status cassandra → active (running).
nodetool status muestra al menos un nodo con Status=UN.
cqlsh se conecta y responde a consultas básicas.
Cambios en cassandra.yaml se aplican tras reiniciar el servicio.

Caja de datos clave

Puertos habituales: 9042 (CQL), 9160 (Thrift).
Tokens por nodo (ejemplo en nodetool): 256.
Dependencias de la guía: OpenJDK 8, Python2 (según paquete).

Glosario (una línea)

CQL: Cassandra Query Language, lenguaje similar a SQL para Cassandra.
nodetool: utilidad de administración y diagnóstico de Cassandra.
Seed node: nodo inicial que ayuda a nuevos nodos a descubrir el clúster.
Factor de replicación: número de copias de los datos por datacenter.
SSTable: formato de almacenamiento en disco utilizado por Cassandra.

Diagrama de decisión rápido

graph TD
  A[¿Necesita escalado horizontal masivo y alta disponibilidad?] -->|Sí| B[Considerar Cassandra o ScyllaDB]
  A -->|No| C[Usar RDBMS o base de datos más simple]
  B --> D[¿Necesita compatibilidad con CQL?]
  D -->|Sí| E[Apache Cassandra]
  D -->|No| F[Explorar otras bases NoSQL]

Conclusión

Has instalado y configurado Apache Cassandra en CentOS 8. Para producción, sigue la mini-metodología, configura monitorización y backups, y prueba la recuperación. Si tienes preguntas específicas sobre un paso, el despliegue en clúster o la optimización, pregúntamelas.

Resumen clave:

Cassandra es adecuada para tolerancia a fallos y escalado horizontal.
Verifica Java, configura el repositorio y crea la unidad systemd.
Prueba con nodetool y cqlsh; aplica configuraciones y reinicia el servicio.