Configurando Cluster Cassandra 3.0 em sistemas baseados em RHEL

Fala galera, tudo bem?

Vamos hoje configurar um cluster no Cassandra com 2 nós como exemplo.

Servidores em um cluster Cassandra são conhecidos como nós. O que você tem em cada servidor é um cluster de Cassandra de nó único. Vamos configurar os nós para funcionar como um cluster de Cassandra multi-nó.

Estou assumindo que você instalou Cassandra em todos os dois nós. Nosso cluster tem a configuração abaixo:




Pare o Cassandra em cada nó se estiver rodando com o comando: service cassandra stop

Limpe a pasta de dados padrão. Estes dados são do cluster antigo que foi instalado durante a instalação em cada nó:

rm -rf /var/lib/cassandra/data/system/*
ps auwx | grep cassandra
kill pid
rm -rf /var/lib/cassandra/data/data/system/*

Vamos realizar algumas configurações do cluster, para isso edite o arquivo: cassandra.yaml com o comando: vi /etc/cassandra/cassandra.yaml. O arquivo pode se encontrar dependendo da instalação em: ls -l /etc/cassandra/conf/.

Os parâmetros abaixo devem ser replicados ou alterados em todos os nós, neste caso nos dois nós.

Node01

cluster_name: 'CassandraClusterTest'  
num_tokens: 256  
seed_provider:  
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
  parameters:
    - seeds: "cass01,cass02"

listen_address: 192.168.0.105  
rpc_address: 0.0.0.0  
broadcast_rpc_address: 192.168.0.105
endpoint_snitch: GossipingPropertyFileSnitch  
auto_bootstrap: false

Node02

cluster_name: 'CassandraClusterTest'  
num_tokens: 256  
seed_provider:  
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
  parameters:
    - seeds: "cass01,cass02"

listen_address: 192.168.0.106  
rpc_address: 0.0.0.0  
broadcast_rpc_address: 192.168.0.106
endpoint_snitch: GossipingPropertyFileSnitch
auto_bootstrap: false

Abaixo algumas informações sobre algumas configurações que fizemos nos dois nós e de alguns parâmetros que existem neste arquivo, cassandra.yaml:

cluster_name: Este é o nome do seu cluster.
-seeds: Esta é uma lista delimitada por vírgulas do endereço IP de cada nó no cluster.
listen_address: Esse é o endereço IP que outros nós do cluster usarão para se conectar a este. Ele assume o padrão localhost e precisa ser alterado para o endereço IP do nó.
rpc_address: Este é o endereço IP para chamadas de procedimento remoto. O padrão é localhost. Se o nome de host do servidor estiver devidamente configurado, deixe isso como está.
endpoint_snitch: Nome do snitch, que é o que diz Cassandra sobre o que sua rede parece. Esse padrão é SimpleSnitch, que é usado para redes em um datacenter. No nosso caso, vamos alterá-lo para GossipingPropertyFileSnitch, que é preferido para as configurações de produção.
auto_bootstrap: Esta diretiva não está no arquivo de configuração, portanto tem que ser adicionada e definida como false. Isso faz com que novos nós usem automaticamente os dados corretos. É opcional se você estiver adicionando nós a um cluster existente, mas necessário quando estiver inicializando um novo cluster, ou seja, um sem dados. Adicione esta configuração somente ao inicializar um novo cluster sem dados

Obs. Para permitir a comunicação entre os nós, as seguintes portas de rede para cada nó precisam estar abertas:

• 22, porta ssh;
• 7000, porta TCP para dados nos nós do cluster;
• 7001, porta SSL no cluster;
• 7199, porta monitoração JMX;
• 9042, porta cliente TCP para o servidor de transporte nativo. Cqlsh, o utilitário de linha de comando Cassandra, se conectará ao cluster por meio desta porta;
• 9160, porta cliente Thrift;
• 9142, porta default transporte SSL.

Para teste se necessário você pode desabilitar o firewall com:

service iptables stop
service ip6tables stop

Agora inicie o Cassandra:

service cassandra start

Antes de iniciar os outros nós do cluster vamos criar um keyspace no node01 para testarmos a replicação entre os nós. Vamos lá:

[root@cass01 /]# nodetool status
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns (effective)  Host ID                               Rack
UN  192.168.0.105  199.85 KB  256          100.0%            f348f14b-cb0f-4cfe-9285-2a998e60d04f  rack1

[root@cass01 /]# cqlsh 192.168.0.105 -u cassandra -p cassandra --cqlversion="3.4.0"
Connected to CassandraClusterTest at 192.168.0.105:9042.
[cqlsh 5.0.1 | Cassandra 3.0.9 | CQL spec 3.4.0 | Native protocol v4]
Use HELP for help.

cassandra@cqlsh>  create keyspace TestKeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : '2' };
cassandra@cqlsh> DESCRIBE keyspaces;

system_schema  system              testkeyspace
system_auth    system_distributed  system_traces

cassandra@cqlsh>
cassandra@cqlsh> exit
[root@cass01 /]#

Depois de criar o keyspace no node01, inicie o serviço no outro nó. Uma vez que o Cassandra começa, você deve ver a imagem como abaixo quando verificar o status do cluster com: nodetool status.

[root@cass01 /]# nodetool status
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns (effective)  Host ID                               Rack
UN  192.168.0.105  163.33 KB  256          100.0%            c9fbc2a8-053a-4633-9cf0-0215d8b46793  rack1
UN  192.168.0.106  120.27 KB  256          100.0%            e9fd9fb3-3587-4ed9-98ae-5951189f9c62  rack1

Obs: Na saída, UN significa que está: Up e Normal:

Validando Cluster

Vamos agora validar a replicação no outro nó.

Conecte no node01 novamente, crie uma tabela e insira um registro como abaixo:

cassandra@cqlsh> use TestKeyspace;
cassandra@cqlsh:testkeyspace> CREATE TABLE emp(
...    emp_id int PRIMARY KEY,
...    emp_name text,
...    emp_city text
...    );

cassandra@cqlsh:testkeyspace>
cassandra@cqlsh:testkeyspace> INSERT INTO emp (emp_id, emp_name, emp_city )
...   VALUES(1, 'EMP 01', 'CIDADE 01' );
cassandra@cqlsh:testkeyspace>
cassandra@cqlsh:testkeyspace> select * from emp;

emp_id | emp_city  | emp_name
--------+-----------+----------
1 | CIDADE 01 |   EMP 01

(1 rows)
cassandra@cqlsh:testkeyspace>

Agora conecte no node02 e verifique o keyspace criado com a nova tabela e o registro inserido, como abaixo, a replicação funcionou:

[root@cass02 /]# cqlsh 192.168.0.106 -u cassandra -p cassandra --cqlversion="3.4.0"
Connected to CassandraClusterTest at 192.168.0.106:9042.
[cqlsh 5.0.1 | Cassandra 3.0.9 | CQL spec 3.4.0 | Native protocol v4]
Use HELP for help.
cassandra@cqlsh> use TestKeyspace;
cassandra@cqlsh:testkeyspace> select * from emp;
emp_id | emp_city  | emp_name
--------+-----------+----------
1 | CIDADE 01 |   EMP 01

(1 rows)
cassandra@cqlsh:testkeyspace>

Observe que você pode especificar o endereço IP de qualquer nó no cluster na mesma máquina para se conectar, veja abaixo:

[root@cass01 /]# cqlsh 192.168.0.105 -u cassandra -p cassandra --cqlversion="3.4.0"
Connected to CassandraClusterTest at 192.168.0.105:9042.
[cqlsh 5.0.1 | Cassandra 3.0.9 | CQL spec 3.4.0 | Native protocol v4]
Use HELP for help.
cassandra@cqlsh> exit

[root@cass01 /]# cqlsh 192.168.0.106 -u cassandra -p cassandra --cqlversion="3.4.0"
Connected to CassandraClusterTest at 192.168.0.106:9042.
[cqlsh 5.0.1 | Cassandra 3.0.9 | CQL spec 3.4.0 | Native protocol v4]
Use HELP for help.
cassandra@cqlsh>

Abraço,

Ronaldo.

Fonte:

https://docs.datastax.com/en/cassandra/3.0/cassandra/initialize/initSingleDS.html
https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureFireWall.html

Nenhum comentário:

Postar um comentário