Des que treballo amb Cassandra he estat apuntant quins errors provocats per la inexperiència hem comés, per tal de no repetir-los. No en parlava gaire perquè algun d’ells em feia veritable vergonya 😀 Però fa poc he vist un video on també parlaven dels errors freqüents amb Cassandra, i hi sortien gairebé tots! El que m’hagués estalviat si hagués existit aquest vídeo quan vaig començar… aix! Però vaja, ara que veig que no som uns negats, sinò que equivocar-se forma part de l’aprenentatge de Cassandra, ja no em fa vergonya, així que aprofitaré el moment per explicar tots els errors, per si a algú altre li pot servir d’ajuda:

Error #1- Fer servir SAN o RAID 1/10/5

Aquests sistemes solucionen problemes inexistents, ja que Cassandra està desenvolupat per aguantar errors en els seus nodes. Per suposat podem afegir una altra capa d’alta disponibilitat en forma de SAN o RAID, però segurament serà més car i menys efectiu que fer-ho afegint més nodes de Cassandra. A més, en el cas de la SAN, si fem que tots els nodes escriguin a la cabina, estem afegint un Single Point of Failure que abans no teniem. Més encara, les dades a Cassandra s’escriuen a diversos servidors alhora, el que significa que processos interns com les compactions les fan tots alhora. Cassandra intenta treure el màxim rendiment possible a la I/O assumint que els discos son propis (com és normal), i el resultat és tots els servidors exprimint la SAN, que no dòna l’abast coordinant les escriptures, i clar, el seu rendiment (i per tant, el del nostre cluster) es veu greument afectat. No només no millorarà el rendiment del nostre cluster amb una SAN, sinò que molt probablement empitjorarà, i amb un cost força elevat. Evidentment pots posar una cabina prou potent com perquè ho pugui suportar, però per la meitat de diners pots millorar el cassandra amb la “Cassandra’s way”: fent servir discos locals, i si volem fer RAID, que sigui RAID0. El cassandra ja és a prova d’errors, deixem que ell mateix faci la seva feina.

Error #2- Posar un load balancer a davant dels Cassandra.

En principi sembla una bona idea: garantim que la càrrega es distribueix i, si un servidor cau, el load balancer el marcarà com a caigut i no li enviarà més connexions fins que es recuperi. Això ja ho tenim els servidors web, i va molt bé, oi? ERROR!! Tornem al mateix que abans: Aquest problema no existeix amb Cassandra. Les dades ja estan distribuides homogèniament entre tots els servidors, i els clients d’alt nivell (com Hector, Astyanax o pycassa) ja s’encarreguen de repartir les lectures i marcar-los quan estan caiguts. A més, afegint un load balancer afegim un Single Point of failure al sistema, quan abans no el tenia, consumim més recursos i encarim l’arquitectura. Fins i tot ens podem trobar que el propi balancejador sigui el coll d’ampolla del nostre sistema, portant més problemes on no els hi havia. El cassandra ja equilibra la càrrega, deixem que ell mateix faci la seva feina.

Error #3- Posar CommitLog i SSTables al mateix disc (no aplicable a discos SSD)

El CommitLog s’està escrivint contínuament de manera seqüencial. Si les SSTables s’han de llegir des del mateix disc, cada lectura molestarà l’escriptura del CommitLog, ja que perdrem la seqüencialitat, el disc haurà de fer seeks, i s’alentirà el procés d’escriptura (recordem que el que limita la velocitat d’escriptura a Cassandra és el que es triga a escriure el CommitLog, perquè la resta es fa en memòria). El CommitLog no necessita gaire espai, però es veu molt afectat pel seek time. A la nostra feina ho menyspreàvem pensant que seria poca la diferència de tenir-ho junt o separat… pero provant en el nostre cluster, on els servidors tenien una càrrega de 7-7.5, vam baixar a 4.5-5 només amb aquest canvi. La nostra cara? Boca oberta primer i facepalm després. Evidentment això no es aplicable a discos SSD on no hi ha seek time.

Error #4- Oblidar instal·lar la JNA (Java Native Access)

Què passa en aquesta màquina on els snapshots triguen més del normal a fer-se? Per què aquest node està més carregat que la resta? Revisa els teus manifests de puppet, perquè amb un 99% de possibilitats no has posat la JNA. La JNA (Java Native Access) fa que la màquina virtual de java pugui interactuar amb els sistemes de fitxers de forma nativa a través del sistema operatiu, i no amb llibreries java que son més lentes e ineficients. D’aquesta manera, interactuar amb fitxers resulta molt més ràpid, i es nota sobretot a l’hora de fer els snapshots. La instal·lació és molt senzilla, i les conseqüències de no instal·lar-la son greus.

Error #5 – No pujar el limit de 1024 file descriptors per Cassandra

Cassandra funciona amb molts sockets i fitxers oberts (hi ha moltes SSTables!), i 1024 (el límit màxim de fitxers per defecte a linux) se’ls acaba força ràpid. És probable que mentre estàs a un entorn de test o d’integració amb poca càrrega no te n’adonis. I també es probable que a producció comencis sense problemes. Però a mesura que van escrivint-se SSTables el número de fitxers oberts va creixent, i quan arribi al màxim el node caurà d’una manera molt lletja, i és probable que arrossegui amb ell a la resta de nodes del cluster. Sobretot, recorda afegir la modificació del limits.conf al teu manifest de puppet!!

Error #6- Posar un tamany de javaHeap superior a 8GB

Tens una màquina amb 64GB de RAM (ole tú!) i penses que, per aprofitar-la, podries donar més memòria al Cassandra, O tens errors de OutOfMemoryError, o et sembla que es fa GarbageCollection massa sovint, o per algún motiu creus que és bona idea pujar la memòria destinada al Heap, i augmentes el javaHeap al cassandra-env.sh. Però no oblidem que el proces de GarbageCollection es força costós, i la seva afectació al cluster augmenta exponencialment amb la quantitat de memòria per alliberar. Per tant, el recomanable son 4-8GB pel javaHeap, i en alguns casos una mica més, fins a 12GB, però només si sabem el que fem i tenim un objectiu amb això. Més de 16GB no s’haurien de posar en cap cas.

Si el que vols es aprofitar aquesta memòria, no et preocupis, Cassandra acabarà aprofitant-la com a page caché del SO.

Error #7- Fer servir els discs Amazon EBS

Els discs EBS d’Amazon tenen un rendiment dolent. Els venen molt bé, però la realitat es que la I/O és molt variable, i podem tenir llargues estones amb una latència molt alta, que ens mati el cluster. És millor fer servir els discos efímers de EC2 que tenen un rendiment més fiable. Sí, si la màquina es mor o l’hem de reiniciar, perdrem les dades d’aquest node i l’haurem de reconstruir… però per això està el nodetool rebuild. I sí, si cau tota la zona on tenim el nostre cluster, haurem de començar de zero, i això es molt arriscat, però si estàs fent servir aws segur que tens els snapshots de les màquinas i de les dades de Cassandra a Amazon S3, i restaurar-les serà ràpid (el Priam de Netflix t’ajudarà a fer-ho). Més informació al respecte.

I aquests són els errors que nosaltres ens hem trobat. Si has llegit això ABANS de començar amb cassandra, t’has estalviat uns quants maldecaps! 😀