Troubleshooting cassandra: Saved cluster name XXXX != configured name YYYY

Si alguna vegada ens trobem que el cassandra no engega, i el log ens apareix el següent error:

INFO [SSTableBatchOpen:3] 2012-10-31 16:51:35,669 SSTableReader.java (line 153) Opening /cassandra/data/system/LocationInfo-hd-56 (696 bytes)
ERROR [main] 2012-10-31 16:51:35,717 AbstractCassandraDaemon.java (line 173) Fatal exception during initialization
org.apache.cassandra.config.ConfigurationException: Saved cluster name XXXX != configured name YYYY
at org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:299)
at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:169)
at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:356)
at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:107)

El problema es que el nom de cluster que apareix al fitxer de configuracio ($CASSANDRA_HOME/conf/cassandra.yaml) es diferent al que hi ha configurat al valor LocationInfo[utf8(‘L’)][utf8(‘ClusterName’)] dintre de la base de dades. Per arreglar-ho, o bé hem de canviar un o bé hem de canviar l’altre.

Canviar el fitxer de configuració es obvi, però si volem canviar l’altre haurem de fer servir el cassandra-cli:

$CASSANDRA_HOME/bin/cassandra-cli -h localhost
use system;
set LocationInfo[utf8('L')][utf8('ClusterName')]=utf8('');
exit;

Això ens pot passar quan volem portar les dades de cassandra d’un cluster a un altre (per exemple, d’un entorn productiu a un entorn que no ho és), o simplement si volvem canviar el nom del cluster de cassandra per qualsevol motiu.

Instal·lació bàsica de apache cassandra (i algunes millores de fine tuning)

Darrerament he treballat molt amb clusters de apache Cassandra, així que aprofitaré per escriure uns quants articles al respecte. Començaré amb el més obvi: la instal·lació de Cassandra. Es un procès molt senzill que encara es pot fer mes fàcil amb els .rpm o .deb que ja existeixen. Però jo ho faré independent de la distro perquè pugui ser útil per tothom, sense importar la distro que faci servir.

1- Prerrequisit: Instal·lar Java Virtual Machine

Per començar, apache cassandra és una aplicació Java, per tant necessitarem la màquina virtual de java (jvm) per poder-la fer servir. Sabem que hi ha vàries versions (openjdk, per exemple), però és molt recomanable fer servir la versió oficial de Sun / Oracle, que podem trobar en el seguent enllaç: http://www.java.com/en/download/linux_manual.jsp?locale=en, o podem instal·lar-la fent servir els gestor de paquets de cada distro (acostuma a estar empaquetada, com a mínim per les principals: redhat, debian, centos, etc).

2- Descàrrega de Cassandra

Després baixem la versió que volguem de Cassandra. Si es la nostra primera instal·lació, voldrem la darrera versió, i la trobarem a la pàgina principal del seu lloc web (ara mateix es la 1.1.6). Després la descomprimim a on volguem (normalment seria /opt però aquí cadascú té les seves preferències) i fem un enllaç simbòlic d’aquest directori a “/opt/cassandra“, per facilitar futures actualitzacions.

cd /opt
wget http://apache.rediris.es/cassandra/1.1.6/apache-cassandra-1.1.6-bin.tar.gz
tar zxvf apache-cassandra-1.1.6-bin.tar.gz
ln -s apache-cassandra-1.1.6 cassandra

3- Gestionant els permisos de l’usuari cassandra

Un bon costum es no donar més privilegis a un servei dels que li fan falta. Per tant, crearem un usari “cassandra” que serà l’usuari amb el que correrà el nostre procés. I ja de pas crearem els directoris que necessitarà l’aplicació per funcionar (logs, pids, etc)

adduser cassandra
mkdir /var/log/cassandra
chown -R cassandra /var/log/cassandra/
mkdir /var/run/cassandra
chown -R cassandra /var/run/cassandra/
mkdir /var/lib/cassandra
chown -R cassandra /var/lib/cassandra/
chown -R cassandra /opt/cassandra/

4- Cassandra com a servei del sistema

Ara voldrem engegar-ho com un servei del sistema. Amb la distribució oficial no ve cap script d’arrencada, però aquí tenim un de stàndard:

wget http://www.tomas.cat/blog/sites/default/files/cassandra.initd -O /etc/init.d/cassandra
chmod a+x /etc/init.d/cassandra
chkconfig --add cassandra
chkconfig cassandra on

Això farà que poguem engengar i aturar cassandra com un servei més del sistema, i que s’engegi quan es reinicia el servidor.

5- Canvis en la configuració de cassandra

Amb això ja tenim un cassandra funcionant amb un sol node. Potser voldrem fer alguns canvis bàsics a la configuració, per exemple la RAM destinada a Cassandra. Per defecte es destina la meitat de la RAM disponible a la HEAP de java, i 100MB per cada CPU de la màquina, pero això es pot modificar al fitxer /opt/cassandra/conf/cassandra-env.sh. També en aquest fitxer es poden modificar les opcions de la cmdline de java, el port de JMX i més coses. Es força auto-explicatiu.

Un altre fitxer que potser ens interessa es /opt/cassandra/conf/cassandra.yaml, on podrem configurar moltes coses, per exemple on es guarden les dades, o l’adreça IP i port pels que volem que el nostre cassandra escolti. Exemples:

  • rpc_address: adreça per on volem que escolti per thrift. Hem de posar una adreça IP de la màquina (pot ser localhost si volem) o 0.0.0.0 si volem que escolti per totes
  • data_file_directories: directori on volem que guardi les dades
  • commitlog_directory: directori on volem que guardi el commit_log
  • saved_caches_directory: directori on volem que guardi les caches

En cas que volguem fer un cluster, també ens interessaran els següents paràmetres:

  • cluster_name: quin nom li volem posar al cluster (ha de ser el mateix per tots els nodes, i MOLT IMPORTANT, diferent entre diferents clusters perque no es trepitgin entre ells)
  • initial_token: el token que li toca a aquest node
  • listen_address: adreça per on volem que es comuniqui per gossip. No pot ser localhost ni 0.0.0.0, perquè la resta de nodes intentaran connectar a l’adreça que digui aquí.
  • seeds: a quin servidor ha de demanar la llista de nodes que formen part del cluster

6 – Fine tune

Hi ha una sèrie de coses que no estan activades per defecte, però que milloren substancialment l’estabilitat i eficiència de cassandra. Jo els posso sempre! Son els següents:

6.1- Fine tune 1 – Script d’arrencada apte per processos d’automatització o batch

El script d’arrencada (init.d) que hem configurat abans té una limitació pel meu parer, i és que, en ser java, el script d’engegada i d’aturada només envia el senyal adient al proces (ja sigui “engega” o “atura’t”) i surt. Per tant, no podem tenir confirmació REAL de que el servei ha engegat correctament, i si un dels nostres processos batch depén d’això, doncs estem fotuts. Per això he afegit unes línies que comproven amb un netcat si el port de thrift està escoltant i, per tant, si el cassandra està actiu i en marxa, abans de retornar a la shell. Les línies en qüestió són les següents:

Primer extreiem dels fitxer de configuracio l’adreça i el port:

CASS_CLI_ADDRESS=cat $CASS_HOME/conf/cassandra.yaml|grep rpc_address|cut -d":" -f2
CASS_CLI_PORT=cat $CASS_HOME/conf/cassandra.yaml|grep rpc_port|cut -d":" -f2

I després en la funció “start” afegim aquesta comprovació:

nc -z -w 1 $CASS_CLI_ADDRESS $CASS_CLI_PORT
while [ $? -ne 0 ]; do
[ date -r $CASS_LOG +%s -lt date -d "$TIMEOUT_LOG minutes ago" +%s ] && echo "Too much time of inactivity in the log file. Aborting..." && exit 1 ;
[ $start_date -lt date -d "$TIMEOUT_STARTUP minutes ago" +%s ] && echo "It's taking too long to start. Aborting..." && exit 1;
sleep 10;nc -z -w 1 $CASS_CLI_ADDRESS $CASS_CLI_PORT; done

Es una mica cutre, però funcional. Quan retornem a la shell tindrem la garantia que el cassandra està en marxa. . Si vols la versió “tunejada”, pots seguir aquest altre procés:

wget http://www.tomas.cat/blog/sites/default/files/cassandra_tuned.initd -O /etc/init.d/cassandra
chmod a+x /etc/init.d/cassandra
chkconfig --add cassandra
chkconfig cassandra on

Recordeu que aquest script necessita del netcat, per tant haureu d’instal·lar-lo per tal que funcioni (“yum install nc“, “apt-get install netcat“, o el que correspongui).

6.2- Fine tune 2 – Habilitar Java Native Access (JNA) a cassandra

L’acces a disc, entre d’altres coses, millora considerablement si es fan servir les llibreries natives del SO en comptes de les de java, que son lentes i consumeixen molts recursos. Aixè ho aconseguim instal·lant JNA, que fa de pont entre el Java i les llibreries natives. Instal·lar-ho es tan fàcil com posar els .jar al directori /opt/cassandra/lib, i cassandra els reconeixerà automàticament

wget https://github.com/twall/jna/blob/3.5.1/dist/jna.jar?raw=true -O /opt/cassandra/lib/jna.jar
wget https://github.com/twall/jna/blob/3.5.1/dist/platform.jar?raw=true -O /opt/cassandra/lib/platform.jar

Podem assegurar-nos que l’està fent servir si mirem el log de cassandra (/var/log/cassandra/system.log). Si no està, apareix aquest missatge:

INFO [main] 2012-09-26 16:52:40,051 CLibrary.java (line 62) JNA not found. Native methods will be disabled.

Si el cassandra l’ha reconegut correctament, apareix aquest altre:

INFO [main] 2012-10-30 16:41:00,970 CLibrary.java (line 109) JNA mlockall successful

6.3- Fine tune 3 – Apujar el limit de Open Files per cassandra

Si li donem una mica de canya, es freqüent que el cassandra necessiti mes de 1024 fitxers oberts (el màxim per defecte). Per evitar que això ens porti problemes, haurem d’editar el fitxer /etc/security/limits.conf i pujar el límit. Un valor prudent es 65536:

root soft nofile 65536
root hard nofile 65536
cassandra soft nofile 65536
cassandra hard nofile 65536

6.4- Fine tune 4 – Limitar la memòria destinada a Cassandra

Finalment, tots coneixem Java i sabem que pots dir-li que faci servir com a màxim certa quantitat de memòria, pero és molt probable que faci servir més memòria. Entre la memòria de la aplicació, més el heap, més el overhead, etc, podem trobar-nos un procés java, configurat per fer servir 8GB de memoria, fent servir 16GB o més. Per assegurar que això no ens passarà, i garantir que la màquina no es quedarà sense memòria, es recomanable posar-hi un límit. En el nostre cas hem considerat oportú posar la meitat de la memòria de la màquina, al fitxer /etc/security/limits.conf :

root soft memlock 8388608
root hard memlock 8388608
cassandra soft memlock 8388608
cassandra hard memlock 8388608

7 – Comprovació de que Cassandra està en marxa

I amb això ja ho tenim tot llest, només hem d’engegar el daemon (“/etc/init.d/cassandra start” o “service cassandra start” o el que correspongui). I podem comprobar el funcionament tant amb el nodetool (es connecta a cassandra via JMX) o amb el cassandra-cli (es connecta a cassandra via thrift). La sortida serà una semblant a aquesta:

[[email protected] ~]# /opt/cassandra/bin/nodetool -h localhost ring
Note: Ownership information does not include topology, please specify a keyspace.
Address DC Rack Status State Load Owns Token
127.0.0.1 datacenter1 rack1 Up Normal 11,21 KB 100,00% 66508542233540571552076363838168202092
[[email protected] ~]# /opt/cassandra/bin/cassandra-cli -h localhost
Connected to: "Test Cluster" on localhost/9160
Welcome to Cassandra CLI version 1.1.6

Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.

[[email protected]] describe cluster;
Cluster Information:
Snitch: org.apache.cassandra.locator.SimpleSnitch
Partitioner: org.apache.cassandra.dht.RandomPartitioner
Schema versions:
59adb24e-f3cd-3e02-97f0-5b395827453f: [127.0.0.1]

[[email protected]] quit;
[[email protected] ~]#

I final!! ja tenim una instal·lació bàsica de cassandra mínimament tunejada.

Com solucionar errors amb el SMTP-AUTH de Postfix (o qualsevol altre servidor de correu) darrere d’un firewall Cisco PIX

Tu has configurat l’autenticació en el correu sortint (SMTP-AUTH) en el teu servidor de correu (Postfix en el nostre cas) i funciona perfectament. Però de sobte quan el poses en producció els usuaris es queixen que no poden enviar correus.

Qué fas? Doncs intentes seguir pas a pas per comprovar el funcionament. És a dir, fas un telnet al port 25 i segueixes pas a pas l’autenticació. La conversa va més o menys així (les línies que comencen per “->” són les que escric jo, sense la part de “->”):

[email protected]:~$ telnet smtp.example.com 25
Trying 1.2.3.4...
Connected to smtp.example.com.
Escape character is '^]'.
220 smtp.example.com ESMTP server ready
-> EHLO example.com
250-smtp.example.com
250 AUTH CRAM-MD5 DIGEST-MD5
-> AUTH FOOBAR
504 Unrecognized authentication type.
-> AUTH CRAM-MD5
334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
-> ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
235 Authentication successful.


Doncs tot funciona… Aleshores li dius al client que faci el mateix, però et diu que no veu la línia “220 smtp.example.com ESMTP server ready”, que només veu una tira d’asteriscs. Ho proves tu mateix, i efectivament és així. I a més a més, no reconeix la comanda AUTH!!


[email protected]:~$ telnet smtp.example.com 25
Trying 1.2.3.4...
Connected to smtp.example.com.
Escape character is '^]'.
220*******************************************************0*2******0***********************
2002*******2***0*00
-> EHLO example.com
250-smtp.example.com
250 AUTH CRAM-MD5 DIGEST-MD5
-> AUTH FOOBAR
500 5.5.2 Error: bad syntax
-> AUTH CRAM-MD5
500 5.5.2 Error: bad syntax

Què passa? Per què aquesta diferència? Doncs sembla que la resposta és senzilla…

Cisco Systems posa a tots els seus routers PIX un protocol per evitar atacs i afegir seguretat. Aquests protocols intercepten totes les comandes que s’envien cap el servidor i les tradueixen, fent de proxy. Aquest protocol es diu MailGuard, i només accepta les comandes bàsiques de SMTP, no pas les exteses ESMTP , fent-lo incompatible amb SMTP-AUTH. Així que la unica manera d’aconseguir fer servir SMTP-AUTH es deshabilitar-ho.

Fer-ho és facil, perquè la comanda és així de senzilla, connectats per telnet al PIX:

no fixup protocol smtp 25
write mem

El més complicat es adonar-se que algú pel mig esta modificant les comunicacions amb el servidor… Pero un cop descobert, problema solucionat!

Fent servir Kubuntu 9.10, o qualsevol distribució linux, des d’un dispositiu USB

Ara ja fa un any vam comentar com fer servir Kubuntu 8.10 des d’un USB. Ara, un any després, em trobava amb el mateix problema, amb la Kubuntu 9.10. Peró des d’aleshores hem fet alguns avenços.

La pròpia Ubuntu porta un programa per fer que un USB arrenqui amb ella mateixa. Al menu hi ha l’aplicació “K-> Aplicacions -> Sistema -> USB Startup Disk Creator” (o també amb la comanda /usr/bin/usb-creator-kde), que es molt senzilla.

Escollim la ISO, escollim el dispositiu USB, i fem click a “Crea un disc d’arrencada”. Esperem una estoneta i ja podem arrencar des d’aquest pendrive.

Peró això nomes serveix per Ubuntu… i la resta de distribucions? Doncs existeix el programa unetbootin, que fa el mateix amb totes les distribucions (bé, com a mínim amb moltes d’elles).

Aqui escollim la distribució, li diem on esta la imatge ISO, a quin dispositiu volem escriure, i s’encarrega de tot.

Evidentment, això només serveix si ho volem fer des de linux. Si voleu fer-ho des de windows, aleshores millor demaneu consell als nostres amics de pendrivelinux

Combatent el SPAM als comentaris del blog: Mollom

Pot passar que la teva feina faci que no puguis actualitzar el teu blog. Fins i tot arribes a no visitar-lo. Aleshores arriba una horda de spammers rabiosos, amb dèria per inundar el teu blog venent Viagres, Cialis i merda semblant. Aquest ha estat exactament el cas d’aquest blog. Resultat? Més de 350.000 comentaris de publicitat, la base de dades plena, no es podien afegir comentaris des de feia mesos… un desastre.

He esborrat els comentaris per tornar a començar des de 0. Peró cinc minuts després ja tenia 20 comentaris SPAM nous! Evidentment s’ha de fer quelcom perquè no torni a passar…

He implementat el sistema Mollom, que a mes de ser capicua (un palíndrom, que se’n diu), es molt potent: fa un anàlisi del text que s’escriu, i si desperta la mes mínima sospita de ser SPAM, aleshores demana un CAPTCHA. Des d’aleshores no ha aparegut cap comentari de SPAM al blog.

La instal·lació ha estat senzillíssima. Primer ens hem de registrar a la web mollom.com, i donar d’alta un un nou site (Site manager -> Add new site). Escollim “Mollom free” i després escollim les quatre dades que ens demana. Al següent pas ens donarà dues claus que haurem d’afegir al nostre blog mes endavant.

Un cop fet això, ve la part del teu site. S’ha de descarregar el modul del projecte mollom a drupal.org, descomprimir-ho al directori de móduls de Drupal, i activar-ho a “Administer -> Site building -> Modules”. Un cop activat, anem a la part de configuració (Administer -> Site configuration -> Mollom) i allá hi posem les claus que ens han donat abans, i configurem quan volem que s’activi el filtre antispam.

Et voilà! Ja ho tenim activat. Hem acabat amb l’SPAM en 5 minuts.