Avviare Cassandra come servizio su Windows 10, 7 e Server

Avvio di Cassandra come servizio su Windows: cosa cambia davvero

Su Windows Cassandra non si comporta come un demone Linux con systemd, quindi il punto non è solo “lanciare il processo”, ma decidere come mantenerlo attivo, come farlo partire al boot e come raccogliere i log senza inseguire finestre di console che si chiudono da sole. Su Windows 10, Windows 7 e Windows Server la logica è la stessa: Java correttamente installato, variabili d’ambiente coerenti, directory di configurazione leggibili, porta di ascolto libera e un metodo affidabile per eseguire il binario o registrarlo come servizio.

Il punto pratico è questo: Cassandra può essere avviata in primo piano da shell per il test, oppure incapsulata in un servizio Windows per l’esercizio continuativo. Per ambienti di laboratorio va bene il primo approccio; per un server o per una macchina che deve restare accesa mesi, il secondo è quello corretto. La differenza non è cosmetica: un servizio ti evita sessioni RDP disconnesse, logout accidentali e riavvii che lasciano il nodo fermo senza che nessuno se ne accorga.

Prerequisiti minimi: Java, memoria e percorso di installazione

Cassandra richiede una versione di Java compatibile con la release che stai usando. Prima di toccare il servizio, verifica che il runtime sia davvero quello atteso e non una vecchia installazione rimasta in giro nel PATH. Su Windows questo è il classico punto che crea falsi positivi: il comando java -version risponde, ma risponde con una JVM diversa da quella che userà il servizio.

Controlla almeno questi elementi: JAVA_HOME, PATH, directory di installazione di Cassandra e spazio libero sul volume che ospita i dati. Se i dati e i commitlog finiscono su un disco quasi pieno, il nodo può partire e poi degradare in modo brutto. Per questo l’avvio non va separato dalla verifica dello storage.

Verifica da prompt amministrativo:

java -version
echo %JAVA_HOME%
where java

Atteso: una sola JVM coerente con la versione supportata dalla tua build di Cassandra, un JAVA_HOME puntato alla stessa installazione e un where java che non elenchi percorsi casuali sotto vecchie cartelle di Oracle, OpenJDK o tool di terze parti.

Avvio manuale per test: utile, ma non basta per la produzione

Prima di registrare un servizio conviene validare il nodo in modo interattivo. In questo modo distingui un problema di Cassandra da un problema del wrapper di servizio. Se il processo fallisce qui, non ha senso andare a caccia di servizi Windows, trigger di avvio automatico o recovery policy.

Dal prompt, posizionati nella directory di Cassandra e avvia il comando previsto dalla distribuzione. In molte installazioni trovi script come bin\cassandra.bat o wrapper equivalenti. L’obiettivo non è la sintassi esatta del pacchetto, che può cambiare tra release e distribuzioni, ma la logica: avvio foreground, osservazione dei log e conferma che il nodo raggiunga lo stato atteso.

cd C:\cassandra\bin
cassandra.bat

Se la console resta aperta e il processo continua a scrivere log, hai già un primo segnale utile. Se invece la finestra si chiude subito o compare un errore Java, il problema va risolto prima di passare al servizio. I casi più comuni sono: heap insufficiente, variabili d’ambiente errate, file di configurazione illeggibili o porta già occupata.

Log da controllare subito: non partire alla cieca

Su Windows il vantaggio principale è che puoi leggere subito l’output della console, ma non devi fermarti lì. Cassandra scrive anche log su file, e quelli sono la fonte che conta quando il processo viene lanciato come servizio. La posizione esatta dipende dal pacchetto, ma di solito trovi directory come logs dentro l’installazione o nel path configurato nei file di startup.

Guarda almeno gli ultimi eventi di avvio: inizializzazione del gossip, bind sulle porte, caricamento delle keyspace system e stato del nodo. Se vedi errori sul bind, il primo sospetto è una porta occupata o un indirizzo non corretto; se il blocco è sullo storage, controlla permessi NTFS e spazio libero; se il problema è Java, torna al controllo della runtime. Il log è il confine tra ipotesi e fatti.

type C:\cassandra\logs\system.log | more

Se preferisci un controllo mirato, cerca parole chiave come ERROR, FATAL, Address already in use, OutOfMemoryError e Permission denied. Sono i segnali che separano un avvio sano da un nodo che si ferma a metà strada.

Installare Cassandra come servizio Windows

Per l’esercizio continuativo serve un servizio vero, non una sessione lasciata aperta. La scelta del metodo dipende dal pacchetto che hai installato: alcune distribuzioni includono uno script dedicato, altre si appoggiano a un wrapper come NSSM o a un servizio personalizzato creato con strumenti Windows. Il criterio tecnico è sempre lo stesso: il servizio deve avviare il processo con l’utente giusto, le variabili giuste e la directory di lavoro corretta.

Se il pacchetto fornisce uno script per il servizio, usalo prima di inventarti soluzioni. Se invece devi creare il servizio da zero, un wrapper è spesso la strada più lineare perché ti consente di definire binario, argomenti, working directory e restart policy senza scrivere codice. In alternativa puoi usare sc.exe, ma per processi Java complessi è meno comodo quando devi passare molte opzioni JVM.

Esempio con wrapper generico: definisci il binario Java, gli argomenti di Cassandra e la cartella di lavoro. Il concetto è questo:

nssm install Cassandra C:\Program Files\Java\jdk-17\bin\java.exe
nssm set Cassandra AppParameters -Xms2G -Xmx2G -Dcassandra.config=file:/C:/cassandra/conf/cassandra.yaml -jar C:\cassandra\lib\cassandra.jar
nssm set Cassandra AppDirectory C:\cassandra

Non prendere questo snippet come comando universale già pronto: il jar, gli argomenti e il path possono cambiare in base al pacchetto. Serve però a fissare la parte importante: il servizio non deve “indovinare” dove si trova Cassandra, deve ricevere un set esplicito di percorsi.

Avvio automatico al boot e account di servizio

Per un nodo Cassandra la scelta dell’account è delicata. Avviare tutto come LocalSystem può sembrare comodo, ma spesso è una scorciatoia che complica accesso a share, permessi su volumi e tracciabilità operativa. Meglio usare un account dedicato con privilegi minimi e accesso solo alle directory necessarie.

Imposta il servizio su avvio automatico e verifica che l’account abbia permessi di lettura e scrittura su installazione, conf, data, commitlog e logs. Se il nodo usa dischi separati, il servizio deve poter scrivere su tutti i mount point coinvolti. Se l’account non ha diritti, il servizio può partire e poi fallire quando prova a creare il primo file, che è un errore più subdolo del classico “service failed to start”.

sc.exe config Cassandra start= auto

Su Windows il controllo finale non è solo “il servizio esiste”, ma anche “riparte dopo reboot”. Dopo la configurazione, esegui un riavvio pianificato o almeno un test di stop/start controllato. Se il servizio non parte al boot, cerca prima nei log del Service Control Manager e poi nei log applicativi di Cassandra.

Windows 10, Windows 7 e Windows Server: differenze operative reali

Dal punto di vista di Cassandra la differenza tra Windows 10 e Windows Server non è la sintassi del servizio, ma il contesto. Su Windows Server hai più spesso account dedicati, policy più rigide e un uso più corretto del servizio in background. Su Windows 10, soprattutto in laboratorio, capita di lavorare da utenti interattivi con meno disciplina sul path e sulle variabili d’ambiente. Windows 7, invece, porta con sé un problema ulteriore: è una piattaforma vecchia, con ecosistema Java e sicurezza molto meno allineati agli standard attuali.

Il risultato pratico è che la procedura è simile, ma la probabilità di incepparsi cambia. Su Windows 7 devi aspettarti più attriti con versioni Java, TLS e compatibilità dei wrapper. Su Windows Server la parte più importante diventa la gestione corretta del servizio, del firewall e della manutenzione. Su Windows 10 il rischio principale è l’uso “da desktop” di un software che in realtà dovrebbe essere trattato come componente server.

Verifica del nodo: non basta che il processo sia vivo

Una volta avviato il servizio, verifica lo stato applicativo e non soltanto quello del processo. Cassandra può essere “running” per il Service Control Manager e allo stesso tempo non essere pronta a gestire traffico. Il nodo deve arrivare a uno stato consistente, completare il bootstrap interno e rispondere alle utility di controllo previste dalla distribuzione.

Controlla i log e, se disponibile, usa gli strumenti di amministrazione del pacchetto per leggere lo stato del cluster o del nodo. L’idea è semplice: processo attivo non equivale a servizio sano. Se il nodo non si registra correttamente o resta in un loop di errori, devi fermarlo e risolvere la causa prima di metterlo in produzione.

type C:\cassandra\logs\system.log | findstr /i "ERROR FATAL exception"
sc.exe query Cassandra

Atteso: il servizio risulta RUNNING e nei log non compaiono errori ricorrenti di bind, storage o JVM. Se compaiono warning isolati non sempre c’è un problema, ma se gli stessi messaggi si ripetono ad ogni avvio hai un difetto strutturale da correggere.

Problemi tipici e come leggerli senza perdere tempo

Il problema più frequente è una JVM non compatibile o non trovata dal servizio. In quel caso la shell manuale può funzionare mentre il servizio fallisce, perché il servizio eredita un ambiente diverso. Il secondo problema classico è la porta occupata: Cassandra tenta di bindare una porta già usata da un altro processo o da una vecchia istanza rimasta appesa. Il terzo è la scrittura su disco: directory senza permessi, volume pieno o path errato nei file di configurazione.

Per ridurre il tempo di diagnosi, separa sempre i controlli in questo ordine: runtime, porte, permessi, spazio, configurazione. Se fai il contrario, finisci a cambiare parametri a caso. Un buon test è guardare il primo errore serio nei log e non l’ultimo: spesso l’errore a cascata è solo una conseguenza del primo fallimento.

Rollback e manutenzione: come non lasciare il nodo in uno stato ambiguo

Ogni modifica al servizio dovrebbe avere un rollback semplice. Se hai cambiato account, path, variabili d’ambiente o argomenti JVM, conserva lo stato precedente in un file di backup o in uno script versionato. Su Windows è facile fare una modifica “al volo” e poi non ricordare più quale opzione abbia rotto l’avvio. Non farlo: salva la configurazione prima di toccarla.

Se il servizio non parte dopo un cambio, torna al profilo precedente prima di fare ulteriori prove. La disciplina utile è questa: una modifica, una verifica, un solo rollback chiaro. Per Cassandra su Windows è particolarmente importante perché i problemi di avvio spesso sembrano generici, ma la causa è quasi sempre locale e ripetibile.

In sintesi operativa: testa Cassandra in console, valida Java e permessi, registra il servizio con percorsi espliciti, imposta l’avvio automatico, controlla i log e conferma il comportamento dopo reboot. Se un passaggio non torna, non forzare l’avvio del servizio: correggi prima la causa e solo dopo ripeti la registrazione o il restart.