Installare Apache Cassandra su CentOS 7

Introduzione

Apache Cassandra è un database NoSQL distribuito, open source, pensato per archiviare grandi quantità di dati su cluster decentralizzati e altamente disponibili. I dati sono replicati su più nodi per eliminare il single point of failure. Questa guida copre l’installazione su CentOS 7 e fornisce indicazioni operative per passare dall’ambiente di test a produzione.

Definizione rapida: NoSQL = database non relazionale che spesso sacrifica alcune proprietà ACID per scalabilità e disponibilità.

Requisiti

Accesso root o sudo sul server CentOS 7
Connessione internet per scaricare pacchetti
Minimo 2 GB di RAM per test; per produzione aumentare in base al carico
Porte: 7000–7001 (internode), 7199 (JMX, nodetool), 9042 (CQL), 9160 (Thrift se usato)

Important: in ambienti di produzione configurare firewall e autenticazione prima di esporre porte sulla rete pubblica.

H1: Installazione passo a passo

Step 1 - Installare JAVA

Prima di installare Cassandra è consigliato aggiornare i pacchetti e i repository:

yum -y update

Quindi scaricare e installare Oracle Java (esempio JDK 8u131). Se non hai wget, installalo con yum -y install wget.

wget --no-cookies --no-check-certificate --header "Cookie:oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/8u131-b11/d54c1d3a095b4ff2b6607d096fa80163/jdk-8u131-linux-x64.rpm"

Installare il pacchetto RPM scaricato:

yum -y localinstall jdk-8u131-linux-x64.rpm

Controllare la versione di Java:

java -version

Output di esempio:

[root@liptan-pc ~]# java -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Controllare la variabile d’ambiente JAVA_HOME:

echo $JAVA_HOME

Se è vuota, impostala modificando il file .bash_profile:

nano ~/.bash_profile

Aggiungi alla fine del file:

export JAVA_HOME=/usr/java/jdk1.8.0_131/
export JRE_HOME=/usr/java/jdk1.8.0_131/jre

Rendi effettive le modifiche:

source ~/.bash_profile

Verifica ancora:

[root@liptan-pc ~]# echo $JAVA_HOME
/usr/java/jdk1.8.0_131/

Note: puoi usare OpenJDK in alternativa a Oracle JDK. OpenJDK è compatibile con Cassandra e spesso preferibile per motivi di licenza.

Step 2 - Installare Cassandra

Aggiungi il repository Apache Cassandra creando un nuovo file:

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

Inserisci questo contenuto nel file:

[cassandra]
name=Apache Cassandra
baseurl=https://www.apache.org/dist/cassandra/redhat/311x/
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://www.apache.org/dist/cassandra/KEYS

Installa Cassandra:

yum -y install cassandra

Ricarica i daemon di sistema e avvia il servizio:

systemctl daemon-reload
systemctl start cassandra
systemctl enable cassandra

Verifica lo stato del cluster con nodetool:

nodetool status

Output di esempio quando il nodo è UP:

[root@ip-172-31-7-136 ~]# nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  127.0.0.1  136.29 KiB  256          100.0%            b3d26649-9e10-4bee-9b3c-8e81c4394b2e  rack1

Se ricevi un errore di connessione JMX come questo:

nodetool: Failed to connect to '127.0.0.1:7199' - ConnectException: 'Connection refused (Connection refused)'.

Devi correggere la configurazione JMX in cassandra-env.sh:

nano /etc/cassandra/default.conf/cassandra-env.sh

Trova e modifica la riga relativa a java.rmi.server.hostname in modo che punti all’indirizzo localhost:

JVM_OPTS="$JVM_OPTS -Djava.rmi.server.hostname=127.0.0.1"

Salva il file e riavvia Cassandra:

systemctl restart cassandra

Verifica nuovamente con nodetool.

Accedere a CQL shell e test rapido

Cassandra include cqlsh per eseguire query in CQL (Cassandra Query Language).

cqlsh

Esempio di avvio:

[root@liptan-pc ~]# cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.

Esempio CQL minimo:

CREATE KEYSPACE IF NOT EXISTS demo WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'};
USE demo;
CREATE TABLE IF NOT EXISTS users (id uuid PRIMARY KEY, name text, email text);
INSERT INTO users (id, name, email) VALUES (uuid(), 'Alice', '[email protected]');
SELECT * FROM users;

Verifiche, test e criteri di accettazione

nodetool status mostra lo stato UP per i nodi attesi
cqlsh si connette e le query SELECT/INSERT funzionano
I log di Cassandra (/var/log/cassandra) non mostrano errori critici

Operazioni comuni e checklist per la produzione

Role-based checklist:

DBA/Storage:
- Verificare il dimensionamento disco e IOPS
- Configurare la politica di compaction e gc_grace_seconds
DevOps:
- Abilitare monitoraggio (metriche JVM, latenza, compaction)
- Configurare backup e procedure di ripristino
Sviluppatori:
- Usare modeling basato su query (denormalizzazione)
- Evitare operazioni che richiedono join o transazioni cross‑partition

Mini-methodology per portare in produzione:

Installare e testare su sandbox
Definire topologia e replication strategy
Testare failover e ripristino dati
Abilitare autenticazione e TLS
Monitorare e ottimizzare risorse

Quando Cassandra non è la scelta giusta

Carichi che richiedono transazioni ACID forti o join complessi
Piccoli dataset con schema relazionale complesso e frequenti query ad hoc
Applicazioni che richiedono basse latenze costanti per transazioni singole con forte consistenza immediata

Alternative e confronto rapido

Relazionali (MySQL, PostgreSQL): quando serve schema relazionale e transazioni forti
MongoDB: se preferisci document store con query flessibili
ScyllaDB: drop-in compatibilità con Cassandra, basata su C++ e orientata a latenze più basse

Modello mentale e concetti chiave

Anello e token: Cassandra distribuisce dati usando token su un anello logico
Replica e consistenza: la consistenza è regolabile per operazione (CONSISTENCY LEVEL)
Partizionamento: progettare le chiavi di partizione per evitare hot‑spot

Sicurezza e hardening

Abilitare l’autenticazione (PasswordAuthenticator) e autorizzazioni RBAC
Abilitare TLS per le connessioni client (internode e client-server)
Limitare l’accesso JMX tramite firewall o binding a localhost
Applicare aggiornamenti di sicurezza e monitorare i log

Backup e ripristino (linee guida)

Snapshot periodici con nodetool snapshot
Copia degli snapshot e dei commitlog in storage esterno
Test periodico del ripristino su ambiente isolato

Esempio di runbook minimo per nodo caduto

Verificare nodetool status e i log in /var/log/cassandra
Riavviare il servizio: systemctl restart cassandra
Se il nodo non rientra: fermare Cassandra, cancellare file lock temporanei, riavviare
Se i dati sono corrotti: ripristinare snapshot più recente e riavviare

1-line glossary

CQL: linguaggio di query di Cassandra
nodetool: strumento di amministrazione per Cassandra
cqlsh: shell interattiva per CQL
Token: intervallo di dati assegnato a un nodo nell’anello

Note di compatibilità e migrazione

Versioni 3.11.x sono largamente usate; verifica la compatibilità del driver prima dell’aggiornamento
Pianificare rolling upgrade per aggiornare cluster con minima perdita di disponibilità

Suggerimenti pratici

Evita partizioni enormi: preferisci chiavi di partizione più distribuite
Monitorare GC della JVM: pause di GC impattano latenza
Valutare il numero di token e la strategia di replica in base alla topologia

Conclusione

Apache Cassandra è ora installato sul tuo server CentOS 7. Questa guida ha spiegato i passaggi di base, come risolvere i problemi JMX, come usare cqlsh e le buone pratiche per mettere Cassandra in produzione. Per approfondire, visita la documentazione ufficiale di Cassandra e testa il comportamento del cluster sotto carico prima di muoverlo in produzione.

Note finali: se pianifichi cluster multi‑nodo, prova una configurazione su più VM e testa il failover e la replica prima della messa in produzione.