Instalando um Cassandra (com Debian e OpenVZ)
Sobre a instalação de um servidor Cassandra sob Debian e OpenVZ
Por que Debian e por que OpenVZ?
São duas escolhas fáceis. A do Debian foi por causa do APT - é muito simples cuidar de um servidor com ele. O OpenVZ foi escolhido por ser a solução mais simples para quem quer virtualizar servidores debaixo do mesmo kernel Linux. Ele é parecido com as partições do Solaris ou com os jails do BSD. Na máquina em que eu fiz a instalação do Cassandra rodam vários servidores, alguns com Debian, outros com CentOS.
O outro motivo para usar um ambiente virtual é que você pode sempre recomeçar do zero quando fez alguma coisa muito errada. Eu já fiz isso mais de uma vez.
Servidor pronto (instalação básica)
Vamos partir do princípio de que temos um servidor virtual Debian 5.0 com as versões mais recentes do básico. O meu básico inclui coisas como munin-node para monitoramento e tuning (outra mão na roda).
Adicionando o repositório ao sources-list
Essa primeira parte é totalmente tirada do wiki do Cassandra. Lá eles tem a página que eu usei para fazer a minha instalação.
A primeira coisa que você precisa fazer é contar para o APT onde ele deve buscar os pacotes que fazem parte da instalação do Cassandra. Para isso, você edita o arquivo /etc/apt/sources.list e acrescenta as duas linhas abaixo:
deb http://www.apache.org/dist/cassandra/debian unstable main deb-src http://www.apache.org/dist/cassandra/debian unstable main
Você ainda vai ter uma surpresa quando der o apt-get update (que faz o APT contactar os repositórios cadastrados e atualizar a lista do que está disponível e em que versão):
W: GPG error: http://www.apache.org unstable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY F758CE318D77295D W: You may want to run apt-get update to correct these problems
Adicionando a chave pública dos pacotes
O APT funciona com assinaturas digitais. Ele não confia, a princípio, em quem assina os pacotes do Cassandra (que não é a galera do Debian) e, por isso, você vai precisar importar a assinatura:
sh-3.2# gpg --keyserver wwwkeys.eu.pgp.net --recv-keys F758CE318D77295D gpg: directory `/root/.gnupg' created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: requesting key 8D77295D from hkp server wwwkeys.eu.pgp.net gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 8D77295D: public key "Eric Evans <[email protected]>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) sh-3.2# gpg --export --armor F758CE318D77295D | apt-key add - OK
Agora você pode fazer o update e o APT vai confiar nos pacotes do Cassandra.
Instalando o Cassandra
As dependências do Cassandra pedem um JRE (um runtime Java). O Debian prefere o OpenJDK. Na minha instalação, não funcionou com ele. Isso não é um grande problema. Tudo o que você precisa é instalar um outro JRE junto com o Cassandra.
Em vez de:
sh-3.2# apt-get install cassandra
Você deve dizer:
sh-3.2# apt-get install sun-java6-jre cassandra
De novo, isso é o que aconteceu comigo (em março de 2010). Pode ser que esse problema tenha sido arrumado quando você seguir essas instruções, pode ser que do meu jeito não funcione e pode ser que o pacote se chame oracle-java7-jre. Resolver isso é com você. Se funcionar para você com o OpenJDK, avise.
O que deu errado
Quando a instalação quase termina, eu sou brindado com:
Setting up cassandra (0.5.0-1) ... Cannot locate Java Home Setting up sun-java6-bin (6-12-1) ... Could not create the Java virtual machine. Error occurred during initialization of VM Could not reserve enough space for object heap Ignoring error generating classes.jsa
A primeira reclamação é do Cassandra. O script de startup dele, em /etc/init.d/cassandra, espera o JRE onde o OpenJDK coloca. Como estamos usando o JRE da Sun, você tem que trocar:
JAVA_HOME="/usr/lib/jvm/java-6-openjdk/jre"
por:
JAVA_HOME="/usr/lib/jvm/java-6-sun/jre"
O segundo problema é mais interessante. Disse o sun-java6-bin que não conseguiu alocar memória para o object heap.
Vamos sair do ambiente virtual e olhar o /proc/user_beancounters do OpenVZ:
Version: 2.5 uid resource held maxheld barrier limit failcnt 2006: kmemsize 1085358 2094306 11055923 11377049 0 lockedpages 0 8 256 256 0 privvmpages 8901 55742 65536 69632 7
O número 7 na linha privvmpages nos dá uma idéia de porque a instalação falhou. Vale lembrar que isso não aconteceria em uma máquina real. Para resolver o problema, você deve aumentar o limite (páginas de memória que o ambiente virtual pode alocar)
root@blackops:/root# vzctl set 2006 --privvmpages 512000 --save
Isso feito, você volta ao servidor virtual e manda que o dpkg reinstale o pacote que reclamou - o sun-java6-bin:
sh-3.2# dpkg-reconfigure sun-java6-bin
Agora podemos levantar o Cassandra:
sh-3.2# /etc/init.d/cassandra start
e ver se ele está mesmo funcionando:
sh-3.2# nodeprobe -host localhost ring Address Status Load Range Ring 127.0.0.1 Up 0 bytes 149143024384283430356665902534805795647 |<--|
O Bônus - fazendo um cluster
Uma das graças de se usar um Cassandra está no clustering. Para fazê-lo eu vou me basear em outra página.
Antes que alguém pergunte, faz muito pouco sentido levantar um cluster em uma única máquina física. O Cassandra é plenamente capaz de usar toda a memória e todos os núcleos que você der pra ele. A única desculpa que eu tenho é querer testar o próprio clustering.
No nosso caso, vamos criar um novo ambiente no OpenVZ igual ao primeiro. Faça todos os passos como fizemos até agora em uma outra máquina (você pode, claro, pular os erros e só fazerr as coisas certas - como, por exemplo, aumentar o privvmpages antes de instalar o sun-java6-jre).
Nos dois servidores, você vai precisar alterar 3 linhas no arquivo /etc/cassandra/storage-conf.xml. Supondo que o IP do seu primeiro servidor seja 192.168.16.105, troque:
<Seed>127.0.0.1</Seed>
por:
<Seed>192.168.16.105</Seed>
Um pouco mais para baixo, troque:
<ListenAddress>localhost</ListenAddress>
por:
<ListenAddress>192.168.16.105</ListenAddress>
e, finalmente,
<ThriftAddress>localhost</ThriftAddress>
por
<ThriftAddress>0.0.0.0</ThriftAddress>
No segundo servidor, faça a mesma coisa trocando o ListenAddress pelo IP do segundo servidor (192.168.16.106), mantendo apenas a tag "<Seed>" com o IP do primeiro.
O que foi que eu fiz?
É simples. O tag Seed lista (pode ter mais de um nó ali) os nós do seu cluster para quem você quer que nós novos perguntem onde estão os outros nós. Não precisa -ou deve - listar todos os nós do cluster, mas, se o cluster tiver muitos nós, é uma idéia listar mais de um. É bom também listar preferencialmente nós locais (dentro do mesmo rack/switch ou datacenter) para que o nó recém chegado possa se orientar mais depressa. Um cluster Cassandra pode estar em mais de um datacenter. No nosso setup, o seed do segundo nó será o 192.168.16.105. Nós subsequentes podem usar qualquer um dos nós anteriores como seeds.
O ListenAddress diz por qual IP cada nó vai mandar e receber dados de sincronização. Lembre-se que no cluster os dados estão espalhados e replicados e os nós precisam, portanto, se comunicar. Você pode usar aí um IP de uma rede dedicada.
E, finalmente, o ThriftAddress é o endereço pelo qual clientes acessam os dados no cluster. 0.0.0.0 diz que ele ouve em todos os seus IPs.
Rufem os tambores...
Restarte os dois Cassandras, entre no primeiro servidor e digite:
sh-3.2# nodeprobe -host 192.168.16.105 ring
Address Status Load Range Ring
149143024384283430356665902534805795647
192.168.16.105Up 1.27 KB 139114487419103335543377020015272155670 |<--|
192.168.16.106Up 652 bytes 149143024384283430356665902534805795647 |-->|
Pronto. Seu próprio cluster Cassandra está no ar. Divirta-se.
