1. Home
  2. Configurando
  3. OpMon
  4. Instalando
  5. Implantação de cluster OpMon (CentOS 6 + MariaDB)

Implantação de cluster OpMon (CentOS 6 + MariaDB)

Objetivo

Demonstrar como configurar um ambiente com dois servidores OpMon em cluster.

Suporte

Essa configuração é suportada pela OpServices para os clientes OpMon Premium e pelos parceiros para os clientes OpMon PRO.

Público-Alvo

Administradores do OpMon.

Pré-Requisitos

  • É preciso ter dois IPs fixos na lan, um para cada nodo do cluster.
  • É preciso ter dois IPs virtuais, um para cada nodo do cluster, para que possa se fazer balanceamento por Round Robin.
  • É preciso que todos os IPs mencionados façam parte da mesma LAN, assim garantindo a comunicação entre os nodos.
  • Os dois servidores devem estar na mesma arquitetura (x86_64 ou i386) e com o mesmo sistema operacional.
  • Os dois servidores devem estar na mesma versão do OpMon.
  • É preciso criar a devida licença, que suporte todos os IPs de ambos nodos, assim terá uma licença para o cluster, ao invés de uma para cada servidor.
  • É necessário realizar a configuração de NTP para a sincronização de horário de ambos servidores, ou com um servidor interno ou externo, caso tenha dúvida de como realizar o procedimento, pode seguir o procedimento descrito aqui.
  • As portas abaixo devem estar liberada para funcionamento do OpMon em cluster:
    • tcp/udp – 80
    • tcp/udp – 443
    • tcp/udp – 5666
    • tcp/udp – 54978
    • tcp/udp – 3306
    • tcp/udp – 694

Premissa importante

  • Entende-se por IP_NODO_MASTER e IP_NODO_SLAVE os IPs que foram configurados nas interfaces eth0 de ambos os nodos.

Configurando um novo cluster

1) Renomear os hosts adequadamente

Para que o cluster funcione corretamente, cada host deve ter um nome diferente. Em outras palavras, quando se rodar o comando ‘uname -n‘ os nomes retornados nos nodos devem ser únicos (diferentes um do outro). Para alterar o hostname dos nodos, basta editar o arquivo /etc/sysconfig/network e definir a opção HOSTNAME corretamente.

Veja o exemplo abaixo, trocaremos o hostname de opmon para opmon-nodo01

[root@opmon ~]# uname -n
opmon
[root@opmon ~]# vim /etc/sysconfig/network

Edite o arquivo para um novo nome:

[root@opmon ~]# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=yes
HOSTNAME=opmon-nodo01
[root@opmon ~]# hostname opmon-nodo01
[root@opmon ~]# uname -n
opmon-nodo01

Repita o processo agora para o Nodo02.

Os novos nomes devem ser anotados pois precisaremos deles mais adiante, quando formos configurar os nodos do cluster.

Importante: O comando hostname troca o nome para a sessão atual, enquanto a edição do arquivo /etc/sysconfig/network faz a mudança persistente.

2) Assegurar a interconectividade entre os nodos:

Configuradas as interfaces eth0 de ambos os nodos, testar a interconectividade entre os nodos usando para tal o comando ping. O acesso pela interface eth0 deve estar funcional, antes de se prosseguir com este tutorial. Para a configuração de rede em ambos os nodos utilizar o utilitário do redhat chamado system-config-network.

3) Atualizar o opmon

O OpMon deve estar na última versão antes da implementação do cluster, para realizar o procedimento siga os passos descritos aqui. Em caso de problemas neste passo o processo deve ser abortado e um contato com a OpServices deve ser feito.

4) Configurando o MariaDB

O servidor MariaDB nesta configuração de cluster será configurado como multi-master. Os dois nodos se comportarão como master e slave ao mesmo tempo. Para tal, precisa-se primeiro configurar a opção de ‘log-bin’, para a geração dos incrementais. Para tal, siga os passos abaixo.

Pare o MariaDB no NODO01:

[root@NODO01 ~]# service mysql stop

Editar o arquivo /etc/my.cnf.d/opmon.cnf e descomentar as 3 linhas abaixo:

log-bin                         =incremental
log-bin-index                   =inc-index
sync_binlog                     =0

Iniciar novamente o MariaDB:

[root@NODO01 ~]# service mysql start

Configurar a senha de acesso ao MariaDB com o seguinte comando:

[root@NODO01 ~]# mysqladmin -u root password 'oppass'

Ajustar o OpMon para que consiga acessar o banco de dados com a senha configurada no último passo. Para tanto, editar o arquivo abaixo e substituir a variável demostrada:

[root@NODO01 ~]# vim /usr/local/opmon/etc/db.php
$DBPASS="oppass";

Logue no MariaDB para autorizar o acesso remoto a partir do NODO02. Em outras palavras, estamos permitindo que conexões ao MariaDB do NODO01 sejam feitas a partir do NODO02:

[root@NODO01 ~]# mysql -p -A -u root
MariaDB [(none)]> GRANT ALL ON *.* TO root@'IP_ETH0_NODO02' IDENTIFIED BY 'oppass'; 
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

Repita o mesmo processo para o Nodo02.

ATENÇÃO: Substituir no passo acima, os nomes IP_ETH0_NODO01 e IP_ETH0_NODO02 pelos respectivos endereços IPs dos dois nodos. Todo procedimento descrito acima deve ser feitos nos dois nodos do cluster, alterando os IPs corretamente.

Exportar a configuração no Nodo01 com o seguinte comando:

[root@NODO01 ~]# /usr/local/opmon/utils/opmon-export.php

Aguardar o processo de export terminar.

Após a execução dos mesmos passos no NODO02, podemos prosseguir. Precisamos agora testar se conseguimos conectar do NODO01 para o NODO02 e vice versa. A partir do NODO01, rodar o seguinte comando:

[root@NODO01 ~]# mysql -u root --password=oppass -h IP_ETH0_NODO02 -e exit && echo OK
OK

Apenas um OK deve aparecer na tela. Repetir o mesmo comando, agora a partir do NODO02:

[root@NODO02 ~]# mysql -u root --password=oppass -h IP_ETH0_NODO01 -e exit && echo OK
OK

Voltamos agora ao NODO01 para efetuarmos um dump da base de dados, com o seguinte comando:

[root@NODO01 ~]# /usr/local/opmon/utils/opmon-base.pl -E 
Logging on file /var/log/opdb-dump.log
2014/10/2 9:28:46 - Starting all databases export
2014/10/2 9:28:46 -  -> Dumping all databases

Verifique se houve algum erro durante o dump, olhando o conteúdo no arquivo /var/log/opdb-dump.log. Em caso de erro, abortar o processo e entrar em contato com a OpServices.

Copiar o dump da base de dados do NODO01 para o NODO02 no mesmo lugar:

[root@NODO01 ~]# scp -r /var/tmp/opmondb root@IP_ETH0_NODO02:/var/tmp/

Acesse o NODO02 e restaurar o dump copiado (para 50GB de dump demora em torno de 6hs, para 86GB em torno de 9hs):

[root@NODO02 ~]# /usr/local/opmon/utils/opmon-base.pl -R

Aguardar o processo de restauração terminar e verificar no arquivo /var/log/opdb-dump.log por possíveis erros. Voltamos então ao NODO01 para então configurarmos a replicação do MariaDB.

5) Ajuste de memória

Ajuste o parãmetro innodb_buffer_pool_size, que é a memória reservada para o banco no /etc/my.cnf.d/opmon.cnf de acordo com cada cliente, por exemplo:

a) Cliente com OpMon e banco no mesmo servidor, usa-se 1/8 da memória, assim temos.

Total RAM Servidor Total RAM Banco
4GB 512M
8GB 1G
16GB 2G
32GB 4G
64GB 8G

b) Cliente com banco dedicado, usa-se até 80% da memória, assim temos.

Total RAM Servidor Total RAM Banco
4GB 3G
8GB 6G
16GB 13G
32GB 26G
64GB 51G

c) Deve-se ajustar o parâmetro tokudb_cache_size de acordo com as regras acima e manter a innodb_buffer_pool_size em 256M. Ficando da seguinte maneira:

# tokudb settings
tokudb_row_format = 'tokudb_snappy'
tokudb_commit_sync = 0
tokudb_loader_memory_size = 100M
tokudb_cache_size = 1G
tokudb_tmp_dir = /var/tmp
tokudb_fs_reserve_percent = 0
tokudb_directio = 0
tokudb_prelock_empty = 0
tokudb_support_xa = 0
tokudb_dir_per_db = 1

# innodb settings
innodb_buffer_pool_size = 256M
innodb_log_file_size = 512M
innodb_log_buffer_size = 16M
innodb_flush_log_at_trx_commit = 0
innodb_lock_wait_timeout = 50
innodb_file_per_table = 1
innodb_support_xa = 0
innodb_log_files_in_group = 2
innodb_thread_concurrency = 8

O procedimento mencionado acima deve ser executado nos dois nodos do OpMon.

No NODO01 edite novamente o arquivo /etc/my.cnf.d/opmon.cnf e descomente as seguintes linhas:

server-id                      =1        
auto_increment_increment       =10       
auto_increment_offset          =1        
slave-skip-errors              =all 

Atenção: As linhas acima são precedidas por uma linha que diz Configuration side A.

No NODO_02 agora, edite o arquivo /etc/my.cnf.d/opmon.cnf também e descomente as seguintes linhas:

server-id                      =2        
auto_increment_increment       =10       
auto_increment_offset          =2        
slave-skip-errors              =all

Ao contrário da configuração do NODO01, as linhas acima são precedidas por uma linha que diz Configuration side B. Observe que o server-id e o auto_increment_offset são diferentes do NODO01.

Reinicie o MariaDB em cada um dos nodos, primeiro no NODO01 e depois no NODO02

[root@NODO01 ~]# service mysql restart
Shutting down MySQL.. SUCCESS!
Starting MySQL. SUCCESS!
[root@NODO02 ~]# service mysql restart
Shutting down MySQL.. SUCCESS!
Starting MySQL. SUCCESS!

Apos isso entrar no MariaDB em cada nodo:

[root@NODO01 ~]# mysql -u root -p 

No NODO1, rodar a seguinte query, trocando IP_ETH0_NODO02 pelo IP da eth0 do NODO02:

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='<IP_ETH0_NODO02>',
    ->                  MASTER_USER='root',
    ->                  MASTER_PASSWORD='oppass',
    ->                  MASTER_LOG_FILE='incremental.000001',
    ->                  MASTER_LOG_POS=0;
Query OK, 0 rows affected (0.03 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

No NODO2, rodar a seguinte query, trocando IP_ETH0_NODO01 pelo IP da eth0 do NODO01:

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='<IP_ETH0_NODO01>',
    ->                  MASTER_USER='root',
    ->                  MASTER_PASSWORD='oppass',
    ->                  MASTER_LOG_FILE='incremental.000001',
    ->                  MASTER_LOG_POS=0;
Query OK, 0 rows affected (0.03 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

Agora precisamos validar se a configuração de multi-master do MariaDB está efetivamente funcionando, para tal logue no MariaDB do NODO01 e rode o comando conforme abaixo:

[root@NODO01 ~]# mysql -u root -p 
Enter password: 

...

MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: 
                Master_Host: 192.168.2.2
                Master_User: root
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: 
        Read_Master_Log_Pos: 4
             Relay_Log_File: mysqld-relay-bin.000001
              Relay_Log_Pos: 98
      Relay_Master_Log_File: 
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: 
        Replicate_Ignore_DB: 
         Replicate_Do_Table: 
     Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
                 Last_Errno: 0
                 Last_Error: 
               Skip_Counter: 0
        Exec_Master_Log_Pos: 0
            Relay_Log_Space: 98
            Until_Condition: None
             Until_Log_File: 
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File: 
         Master_SSL_CA_Path: 
            Master_SSL_Cert: 
          Master_SSL_Cipher: 
             Master_SSL_Key: 
      Seconds_Behind_Master: NULL
1 row in set (0.00 sec)

Devemos observar as seguintes linhas:

...
Slave_IO_Running: Yes 
Slave_SQL_Running: Yes
...

Ambas devem estar em Yes. Caso elas não estejam em Yes, aguardar um minuto e tentar o comando novamente. Se elas não ficarem em Yes, significa um problema. Abortar o processo e contatar a OpServices. Repetir o mesmo processo, agora no NODO02:

[root@NODO02 ~]# mysql -u root -p 
Enter password: 

...

MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 192.168.2.1
                Master_User: root
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: incremental.000003
        Read_Master_Log_Pos: 172320
             Relay_Log_File: mysqld-relay-bin.000005
              Relay_Log_Pos: 172459
      Relay_Master_Log_File: incremental.000003
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: 
        Replicate_Ignore_DB: 
         Replicate_Do_Table: 
     Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
                 Last_Errno: 0
                 Last_Error: 
               Skip_Counter: 0
        Exec_Master_Log_Pos: 172320
            Relay_Log_Space: 172459
            Until_Condition: None
             Until_Log_File: 
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File: 
         Master_SSL_CA_Path: 
            Master_SSL_Cert: 
          Master_SSL_Cipher: 
             Master_SSL_Key: 
      Seconds_Behind_Master: 0
1 row in set (0.00 sec)

mysql> exit

Ficando Yes em ambas as opções acima nos dois nodos, o próximo passo é testar a sincronismo de base. As operações abaixo podem atrasar um pouco para acontecer, pois as bases podem estar sincronizando, mas como testamos a configuração com o comando “show slave status\G” o sincronismo deverá acontecer.

No NODO01 acessar o mariadb e rodar o seguinte comando:

[root@NODO01 ~]# mysql -u root -p 
Enter password: 

...

MariaDB [(none)]> create database testesincronismo; 
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> exit

Agora, no NODO02, verificar se a base de dados criada acima (testesincronismo) existe:

[root@NODO02 ~]# mysql -u root -p
Enter password: 

...

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema | 
| Syslog             | 
| mysql              | 
| nedi               | 
| opcfg              | 
| opmon4             | 
| opperf             | 
| seagull            | 
| snmptt             | 
| test               | 
| testesincronismo   | 
+--------------------+
11 rows in set (0.00 sec)

Se a base de dados não existir, aguarde um tempo pois o sincronismo pode estar um pouco atrasado. Caso ele não apareça em alguns minutos, abortar o processo. Em caso afirmativo, temos a certeza de que a sincronização do NODO01 para o NODO02 está funcionando corretamente, precisamos agora testar o inverso, ou seja, o sincronismo do NODO02 para o NODO01. Para tanto, basta removermos a base de dados testesincronismo no mysql do NODO02 e ela deverá sumir também no NODO01 conforme abaixo:

No NODO02:

[root@NODO02 ~]# mysql -u root -p
Enter password: 

...

MariaDB [(none)]> drop database testesincronismo;
Query OK, 0 rows affected (0.00 sec)

E no NODO01, a base deverá ter sumido:

[root@NODO01 ~]# mysql -u root -p
Enter password: 

...

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema | 
| Syslog             | 
| mysql              | 
| nedi               | 
| opcfg              | 
| opmon4             | 
| opperf             | 
| seagull            | 
| snmptt             | 
| test               | 
+--------------------+
10 rows in set (0.00 sec)

MariaDB [(none)]>

Com isso, encerramos a configuração do MySQL dos dois nodos do cluster. A configuração fica como especificado abaixo (a imagem abaixo é a mesma do procedimento do MySQL, mas a ideia permanece):

08

6) Configurando o SSH sem senha

Para que haja um sincronismo de arquivos físicos entre os nodos, se faz necessário permitir o login via SSH de um nodo para o outro sem a necessidade de senha. Para tal, teremos que gerar as chaves criptográficas em ambos os nodos. No NODO01 executar:

[root@NODO01 ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
43:43:fa:d6:3a:41:91:f9:22:5f:63:b2:36:b2:d8:7d root@homolog-nodo01
[root@NODO01 ~]#

Apenas pressione ENTER em todas as perguntas feitas. Agora que a chave foi criada no NODO01, precisamos copiar a parte pública dela para o NODO02. Para isso, rodamos o seguinte comando:

[root@NODO01 ~]# ssh-copy-id <IP_ETH0_NODO02>
Now try logging into the machine, with "ssh '192.168.10.126'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

[root@NODO01 ~]# 

Agora precisamos testar o acesso do NODO01 ao NODO02 via SSH e a senha não deverá ser perguntada. Para tanto, basta a partir do NODO01 acessar via SSH o NODO02. Feito o teste e validando o acesso ssh sem senha, devemos repetir o processo todo no NODO02, ou seja, geramos a chave, copiamos a parte publica para o NODO1 e testamos novamente o acesso ssh.

7) Configurando o sincronismo de arquivos

Primeiro precisamos validar se o utilitário rsync se encontra instalado em ambas as máquinas. Para isso, mandamos instala-lo via yum:

[root@NODO01 ~]# yum install rsync -y
[root@NODO02 ~]# yum install rsync -y

Agora, no NODO01, precisamos editar o arquivo /etc/syncfiles.conf e configurar os IPs conforme abaixo:

[root@NODO01 ~]# vim /etc/syncfiles.conf

Devemos deixar os seguintes parâmetros com a seguinte configuração:

PORT=22
SLEEPTIME=60
HOST=IP_ETH0_NODO02

Agora a configuração inversa deve ser feita no NODO02, ou seja:

[root@NODO02 ~]# vim /etc/syncfiles.conf

Devemos deixar os seguintes parâmetros com a seguinte configuração:

PORT=22
SLEEPTIME=60
HOST=IP_ETH0_NODO01

Voltamos agora nossa atencão novamente ao NODO01. No diretório /etc/syncfiles.d devem conter os seguintes arquivos, conforme abaixo:

etc.conf
libexec.conf
syncfilesd.conf
var.conf
license.conf

Muitas vezes, por padrão o arquivo license.conf não vem criado. Caso ocorra isso, crie o arquivo license.conf dentro do diretório /etc/syncfiles.d com o seguinte conteúdo:

dir=/usr/local/opmon/lic
to=/usr/local/opmon/

Salve e saia do arquivo.

Pronto, temos agora a configuração do sincronismo dos arquivos configurada. Precisamos apenas testá-la. Para tanto rodamos o comando a seguir no NODO01:

[root@nodo01 ~]# service syncfiles start
Starting cluster's syncronization script
[root@nodo01 ~]#

Verificamos o arquivo /var/log/syncfiles.log procurando por possíveis erros de sincronismo. Caso tudo esteja OK, devemos parar o processo de sincronismo e deixá-lo parado por enquanto:

[root@nodo01 ~]# service syncfiles stop
Stopping cluster's syncronization script
[root@nodo01 ~]#

8) Configurando Pacemaker e CMAN

O pacemaker e o CMAN são os utilitários que mantém o OpMon funcionando, mesmo com a queda de um dos nodos. Precisamos agora configurá-los. Primeiramente precisamos tirar o processo do OpMon e do syncfiles do boot das máquinas, pois quem vai gerenciar se estes devem subir ou não será o Pacemaker a partir de agora. Para tanto, nos dois nodos, rodar os seguintes comandos:

[root@nodo01 ~]# chkconfig --del syncfiles
[root@nodo01 ~]# chkconfig --del opmon
[root@nodo01 ~]# chkconfig --del gearmand
[root@nodo01 ~]# service  syncfiles stop
[root@nodo01 ~]# service  opmon stop
[root@nodo01 ~]# service  gearmand stop
[root@nodo02 ~]# chkconfig --del syncfiles
[root@nodo02 ~]# chkconfig --del opmon
[root@nodo02 ~]# chkconfig --del gearmand
[root@nodo02 ~]# service  syncfiles stop
[root@nodo02 ~]# service  opmon stop
[root@nodo02 ~]# service  gearmand stop

Vamos agora instalar os pacotes para que o cluster funcione corretamente. Nos dois nodos precisamos rodar o seguinte comandos:

[root@NODO01 ~]# yum install pacemaker cman pcs ccs resource-agents crmsh
[root@NODO02 ~]# yum install pacemaker cman pcs ccs resource-agents crmsh

Agora precisamos nos certificar de que todos os nodos estão listados em /etc/hosts. Para isso, basta editar o arquivo citado acima e inserir as entradas como as que seguem, ajustando obviamente o IP para o correspondente:

<IP_ETH0_NODO01>  NODO01
<IP_ETH0_NODO02>  NODO02

Repita o processo no NODO02.

Agora precisamos gerar as chaves do corosync (este procedimento pode tomar um tempo, e é importante que se digite caracteres aleatórios para auxiliar na entropia da chave criada):

ATENÇÃO: Algumas partes do procedimento a seguir devem ser executadas em apenas um host, portanto atente para as caixas de diálogo, pois estas informa em qual NODO a operação está sendo executada.

[root@NODO01 ~]# corosync-keygen

Após a criação da chave, movemos esta para o diretório de configuração do cluster, como segue:

[root@NODO01 ~]# mv /etc/corosync/authkey /etc/cluster/corosync.key

Movemos agora o exemplo do arquivo cluster.conf para o diretório de configuração do cluster:

[root@NODO01 ~]# mv /usr/local/opmon/utils/cluster/cluster.conf /etc/cluster/

Editamos agora o arquivo /etc/cluster/cluster.conf e definimos os nodos do cluster (veja exemplo abaixo):

   <cluster config_version="9" name="cluster">
     <fence_daemon/>
     <clusternodes>
       <clusternode name="nodo1" nodeid="1">
         <fence>
           <method name="pcmk-redirect">
             <device name="pcmk" port="nodo1"/>
           </method>
         </fence>
      </clusternode>
      <clusternode name="nodo2" nodeid="2">
        <fence>
          <method name="pcmk-redirect">
            <device name="pcmk" port="nodo2"/>
          </method>
        </fence>
      </clusternode>
    </clusternodes>
    <cman keyfile="/etc/cluster/corosync.key" expected_votes="1" two_node="1" transport="udpu" />
    <fencedevices>
      <fencedevice agent="fence_pcmk" name="pcmk"/>
    </fencedevices>
    <rm>
      <failoverdomains/>
      <resources/>
    </rm>
  </cluster>

As propriedades que devem ser alteradas no XML(cluster.conf) são a clusternode e device, subsituindo onde está opdev1 e opdev2 pelo nome efetivos dos nodos.

Agora copiamos os arquivos /etc/cluster/corosync.key e /etc/cluster/cluster.conf para todos os nodos, para isso podemos usar o comando scp, conforme abaixo:

[root@NODO01 ~]# scp /etc/cluster/corosync.key /etc/cluster/cluster.conf root@<IP_ETHO_NODO02>:/etc/cluster/
corosync.key                        100%  128     0.1KB/s   00:00
cluster.conf                        100%  703     0.7KB/s   00:00 
[root@NODO01 ~]#

Precisamos agora ajustar a configuração do CMAN, para isso editamos o arquivo:

[root@NODO01 ~]# vim /etc/sysconfig/cman

Descomente a configuração e altere para 0, conforme abaixo:

CMAN_QUORUM_TIMEOUT=0

Este mesmo procedimento deve ser adotado no NODO02:

[root@NODO02 ~]# vim /etc/sysconfig/cman
...
CMAN_QUORUM_TIMEOUT=0

Iniciamos agora os serviços do cluster e os adicionamos ao boot dos servidores:

[root@NODO01 ~]# service cman start
...
[root@NODO01 ~]# service pacemaker start
...
[root@NODO01 ~]# chkconfig --level 35 cman on
[root@NODO01 ~]# chkconfig --level 35 pacemaker on

Agora, no NODO02, repetimos:

[root@NODO02 ~]# service cman start
...
[root@NODO02 ~]# service pacemaker start
...
[root@NODO02 ~]# chkconfig --level 35 cman on
[root@NODO02 ~]# chkconfig --level 35 pacemaker on

No NODO01 agora, definimos a configuração padrão do Pacemaker, utilizando o comando: crm configure, conforme o prompt abaixo:

[root@NODO01 ~]# crm configure
crm(live)configure#  property start-failure-is-fatal=false
crm(live)configure#  property stonith-enabled=false
crm(live)configure#  property no-quorum-policy=ignore
crm(live)configure#  rsc_defaults rsc_defaults-options: migration-threshold=0 failure-timeout=2s resource-stickiness=50

Adicionamos agora os IPs virtuais que usaremos para acesso web (round-robin), com os seguintes comandos:

crm(live)configure# primitive Virtual_Ip_Nodo01 ocf:heartbeat:IPaddr2 params ip=<IP_VIRTUAL_NODO01> cidr_netmask=32 op monitor interval=30s
crm(live)configure# primitive Virtual_Ip_Nodo02 ocf:heartbeat:IPaddr2 params ip=<IP_VIRTUAL_NODO02> cidr_netmask=32 op monitor interval=30s

Lembre-se de substituir as variáveis corretamente com os ips virtuais que serão usados no round-robin.

Passamos agora a definir os processos e serviços que serão controlados pelo Pacemaker/cluster:

crm(live)configure# primitive opmon-pri lsb:opmon op monitor interval="10" timeout="30" op start interval="0" timeout="120" op stop interval="0" timeout="240"
crm(live)configure# primitive syncfiles-pri lsb:syncfiles op monitor interval="10" timeout="30" op start interval="0" timeout="120" op stop interval="0" timeout="120"
crm(live)configure# primitive opdiscovery-pri lsb:opdiscovery op monitor interval="10" timeout="30" op start interval="0" timeout="120" op stop interval="0" timeout="120"
crm(live)configure# primitive gearmand-pri lsb:gearmand op monitor interval="10" timeout="30" op start interval="0" timeout="120" op stop interval="0" timeout="120"
crm(live)configure# primitive gearman-utils-pri lsb:gearman-utils op monitor interval="10" timeout="30" op start interval="0" timeout="120" op stop interval="0" timeout="120"
crm(live)configure# primitive memcached-pri lsb:memcached op monitor interval="10" timeout="30" op start interval="0" timeout="120" op stop interval="0" timeout="120"
crm(live)configure# primitive postfix-pri lsb:postfix op monitor interval="10" timeout="30" op start interval="0" timeout="120" op stop interval="0" timeout="120"
crm(live)configure# primitive opmonconnector-pri lsb:opmonconnector op monitor interval="10" timeout="30" op start interval="0" timeout="120" op stop interval="0" timeout="120"

Agora precisamos definir um grupo de primitivas, pois os mesmos devem rodar em apenas um servidor:

crm(live)configure# group OpmonProcesses syncfiles-pri opmon-pri
crm(live)configure# group OpmonExtraProcesses gearmand-pri opmonconnector-pri gearman-utils-pri memcached-pri opdiscovery-pri postfix-pri

Feita a adição dos IPs virtuais, agora precisamos definir o local dos IP Virtuais subirão, lembrando que NODO01 e NODO02 devem ser substituídos pelos hostnames dos nodos em questão:

crm(live)configure# location Loc_vip_nodo01 Virtual_Ip_Nodo01 100: NODO01
crm(live)configure# location Loc_vip_nodo02 Virtual_Ip_Nodo02 100: NODO02
crm(live)configure# location Loc_OpmonProcesses OpmonProcesses inf: NODO01

Por último, devemos devemos realizar uma clonagem de grupos:

crm(live)configure# clone OpmonExtraProcesses_Clone OpmonExtraProcesses

Saindo e salvando as configurações, execute o seguinte comando:

crm(live)configure# commit
crm(live)configure# end
There are changes pending. Do you want to commit them (y/n)? y
crm(live)# quit
bye

Podemos ter algum problema no commit das informações. Também podemos adotar outra tática, ou seja, irmos adicionandos os recursos (IPs virtuais, processos, grupos) e ir sempre saindo e fazendo commit das informações.

Para visualizarmos todas as configurações feitas até o momento, devemos usar o comando crm configure show conforme exemplo abaixo:

[root@NODO01 ~]# crm configure show
node opservices-opmon-nodo01-pae \
       attributes standby=off
node opservices-opmon-nodo02-pae
primitive gearman-utils-pri lsb:gearman-utils \
       op monitor interval=10 timeout=30 \
       op start interval=0 timeout=120 \
       op stop interval=0 timeout=120
primitive gearmand lsb:gearmand \
       op monitor interval=10 timeout=30 \
       op start interval=0 timeout=120 \
       op stop interval=0 timeout=120
primitive memcached-pri lsb:memcached \
       op monitor interval=0 int
primitive mod_gearman_worker-pri lsb:mod_gearman_worker \
       op monitor interval=10 timeout=30 \
       op start interval=0 timeout=120 \
       op stop interval=0 timeout=120
primitive opdiscovery-pri lsb:opdiscovery \
       op monitor interval=10 timeout=30 \
       op start interval=0 timeout=120 \
       op stop interval=0 timeout=120
primitive opmon lsb:opmon \
       op monitor interval=10 timeout=30 \
       op start interval=0 timeout=120 \
       op stop interval=0 timeout=240
primitive opmonconnector-pri lsb:opmonconnector \
       op monitor interval=10 timeout=30 \
       op start interval=0 timeout=120 \
       op stop interval=0 timeout=120
primitive optraffic-pri lsb:optrafficd \
       op monitor interval=10 timeout=30 \
       op start interval=0 timeout=120 \
       op stop interval=0 timeout=120
primitive postfix-pri lsb:postfix \
       op monitor interval=10 timeout=30 \
       op start interval=0 timeout=120 \
       op stop interval=0 timeout=120
primitive syncfiles lsb:syncfiles \
      op monitor interval=10 timeout=30 \
      op start interval=0 timeout=120 \
      op stop interval=0 timeout=120 \
      meta target-role=Started
primitive vip_nodo01 IPaddr2 \
      params ip=<IP_VIRTUAL_NODO01> cidr_netmask=32 \
      op monitor interval=30s \
      meta target-role=Started
primitive vip_nodo02 IPaddr2 \
     params ip=<IP_VIRTUAL_NODO02> cidr_netmask=32 \
     op =30s
group OpmonExtraProcesses opdiscovery-pri mod_gearman_worker-pri gearman-utils-pri memcached-pri postfix-pri gearmand opmonconnector-pri
group opmonprocesses syncfiles opmon optraffic-pri \
     meta target-role=Started
clone OpmonExtraProcesses_Clone OpmonExtraProcesses
location cli-ban-vip_nodo02-on-opservices-opmon-nodo02-pae vip_nodo02 role=Started -inf: opservices-opmon-nodo02-pae
location loc_opmonprocesses opmonprocesses inf: opservices-opmon-nodo01-pae
location loc_vip_nodo01 vip_nodo01 100: opservices-opmon-nodo01-pae
location loc_vip_nodo02 vip_nodo02 100: opservices-opmon-nodo02-pae
property cib-bootstrap-options: \
     dc-version=1.1.15-5.el6-e174ec8 \
     cluster-infrastructure=cman \
     start-failure-is-fatal=false \
     stonith-enabled=false \
     no-quorum-policy=ignore \
     have-watchdog=false
rsc_defaults rsc_defaults-options: \
     migration-threshold=0 \
     failure-timeout=2s \
     resource-stickiness=50

9) Modgearman

Passaremos agora a configurar o módulo gearman para o core do OpMon, chamado de modgearman. Este é composto por dois itens, um chamado de worker e outro chamado de neb. O neb sobre sempre junto ao processo do OpMon, enquanto o worker deve rodar nos dois nodos pois é ele quem executa as checagens. Em outras palavras, o neb escala as checagens e o worker as executa. Como o processo gearmand sempre roda junto ao processo do OpMon, precisamos configurar o neb para que escale as checagens para o gearmand local, onde todos os workers estão conectados. Para isso, basta alterarmos o arquivo /etc/mod_gearman/mod_gearman_neb.conf conforme abaixo:

server=127.0.0.1:4730

Este processo deve ser executado em ambos os nodos.

Feito este procedimento agora precisamos inserir o endereço IP do NODO01 em nossa configuração de job servers. Acessando agora a interface do OpMon através do NODO01 clique em “Ferramentas”, logo após em “Configurações“, localize a opção “Main Config e então “Job Servers”, veja:

Dica: Em ambientes clusterizados o job server deve ser o IP Virtual do nodo principal, no nosso caso, o NODO01.

Agora nos resta reiniciar alguns processos para que subam com as novas configurações de Job Servers, este processo deve ser executado nos dois nodos:

[root@NODO01 ~]# /etc/init.d/gearman-utils restart
[root@NODO01 ~]# /etc/init.d/mod_gearman_worker restart
[root@NODO02 ~]# /etc/init.d/gearman-utils restart
[root@NODO02 ~]# /etc/init.d/mod_gearman_worker restart

10) Configurando o clean-incrementals

O processo de clean-incrementals limpa os arquivos incrementais do MariaDB que não são mais necessários. Antes de proceder com esta configuração precisamos assegurar que as bases de dados dos dois nodos estão 100% sincronizadas senão corremos o risco de perder dados. Em ambos os nodos logue no mysql e execute:

[root@NODO01]#mysql -p -A

...

MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 172.19.0.2
                Master_User: root
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: incremental.000005
        Read_Master_Log_Pos: 348
             Relay_Log_File: mysqld-relay-bin.000015
              Relay_Log_Pos: 487
      Relay_Master_Log_File: incremental.000005
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 348
            Relay_Log_Space: 487
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0

Se os itens _Slave_IO_Running_ e Slave_SQL_Running estiverem como Yes, e Seconds_Behind_Master como ZERO, significa que a base está plenamente sincronizada, caso o Seconds_Behind_Master seja maior que ZERO, espere até o sincronismo finalizar para seguir os próximos passos.

Assim que o sincronismo estiver OK, no NODO01 editar o arquivo /usr/local/opmon/utils/clean-incrementals.pl e colocar o ip do NODO02 na variável:

$slave_address = "192.168.2.2";

Editar o mesmo arquivo, agora no NODO02 e colocar o IP do NODO01 conforme abaixo:

$slave_address = "192.168.2.1";

Agora, com a configuração feita, retornamos ao NODO01 e executamos:

[root@NODO01 ~]# /usr/local/opmon/utils/clean-incrementals.pl

Após a finalização do comando acima, faremos o mesmo processo porém agora no NODO02:

[root@NODO02 ~]# /usr/local/opmon/utils/clean-incrementals.pl

Agora só precisamos habilitar o agendamento da limpeza dos incrementais. No NODO01 editamos o arquivo /etc/cron.d/clean-incrementals e descomentamos a linha que faz referência ao clean-incrementals:

0 23 * * * root /usr/local/opmon/utils/clean-incrementals.pl >/dev/null 2>/dev/null

E reiniciamos o processo da crond. Devemos agora ir ao NODO02 e executar o mesmo procedimento editando o arquivo da crond e reiniciando o processo.

11) Fornecendo acesso ao Livestatus somente aos IPs do Cluster

Por questões de segurança dos dados, é importante que no arquivo de configuração do livestatus sejam listados somente o IP do OpMon e do cluster (IPs físicos e não virtuais). Para isso basta editar o seguinte arquivo de configuração /etc/xinetd.d/livestatus e incluir o(s) IP(s) do cluster, conforme o exemplo abaixo ilustrado:

only_from       = 127.0.0.1 IP_FÍSICO_1 IP_FÍSICO_2

 

Checklist de validação do cluster

  • Colocar a nova licença no nodo1 (suportando todos IPs de ambos nodos) que vai sincronizar para o nodo2.
  • Validar se a licença sincronizou (o arquivo de licença deverá ser o mesmo nos dois nodos).
  • Reiniciar o httpd em ambos nodos.
  • Acessar o ip físico do NODO01 no browser.
  • Acessar o ip físico do NODO02 no browser.
  • Acessar também pelos ips virtuais.
Updated on abril 4, 2018

Was this article helpful?