Arquivo da categoria: Alta Disponibilidade

Esta categoria aborda assuntos relacionados a Alta Disponibilidade de ambientes Linux de missão crítica.

Failover automático com Keepalived

Alta disponibilidade é um assunto sempre discutido entre as rodas de nerds e pela alta cúpula das corporações. Afinal, garantir que sua aplicação esteja disponível mesmo em caso de uma presente falha, é algo que chama muito a atenção, e claro, isso faz com que o pessoal da área estratégica e negócio das corporações fiquem fascinados e motivados a implementar essas soluções em seu ambiente de tecnologia.

Porém quando esse assunto é discutido, são envolvidas muitas teorias que fazem desse tipo de solução algo extremamente complexo ou mesmo místico, chegando beirar o nebuloso entre alguns profissionais da área.

Antes de iniciarmos a parte prática é importante entendermos que alta disponibilidade é um conceito, não um serviço, então logicamente existem dezenas de ferramentas que oferecem essa solução.

Resumindo, de forma breve, a alta disponibilidade é garantir que minha aplicação ou serviço fique no ar mesmo em caso de falha. E esse serviço ou aplicação tem um IP que é popularmente conhecido como VIP (Virtual IP), esse VIP é um endereço IP flutuante, que fica no servidor ativo, ou seja, o mestre do cluster, isso quando estamos trabalhando com o modelo failover (passivo/ativo), onde você tem um mestre e um escravo. Quando você trabalha com o modelo de balanceamento de carga, o endereço VIP, é o IP flutuante do seu servidor e/ou balanceador de carga, que tem o papel de distribuir as requisições para o pool de servidores que esta atrás dele. Caso você queira saber mais sobre alta disponibilidade, segue o link onde esse assunto foi abordado em seu conceito de forma mais extensa: Link de HA

No post de hoje não só vamos esclarecer como funciona o faliover como vamos implementá-lo na prática. Importante salientar que o keepalived também pode trabalhar em balanceamento de carga em conjunto com ipvsadm, que usa o recurso de IPVS do kernel Linux, que nada mais é que um balanceador de carga sob camada 4 do modelo OSI (Camada de transporte).

A solução open source que vamos adotar neste post como já esclarecido acima é o keepalived, uma solução extremamente eficiente e digna de respeito, apresentando-se uma alternativa a altura do “falecido” projeto heartbeat, antiga solução de failover que foi muito adotada pela comunidade open source no passado.

Obviamente existem outras soluções que atendem esse propósito e que são até mais populares que o próprio keepalived, como o Pacemaker por exemplo, porém aqui no post foquei no objetivo de exemplificar e praticar o assunto de alta disponibilidade passivo/ativo de forma simples. Obviamente uma solução como o pacemaker é excelente, e atende diversos requisitos que provavelmente o keepalived não atenda, enquanto o pacemaker é uma ferramenta completa de alta disponibilidade, focada totalmente em prover tolerância a falha e gerenciamento de cluster.

Já deu né? Agora bora por a mão na massa! Como de praxe, faremos nas duas principais famílias de distribuições Linux do mercado: Debian (8) e CentOS (7).

Primeiramente vamos definir nosso ambiente. Para esse laboratório você precisa de 2 servidores no mínimo, sendo um mestre e um escravo (independente da distro que você escolher).

Então vamos para provavelmente o passo mais importante, instalar o keepalived. O keepalived esta disponível através do repositório da distribuição, com exceção da família Red Hat, onde o mesmo esta disponível via repositório EPEL (Extras Packages Enterprise Linux), caso você use o Red Hat puro, acionar o suporte da Red Hat para habilitar o repositório correto conforme orientação do suporte da mesma.

O failover que faremos aqui será em cima do serviço nginx, apenas porque optei por fazê-lo com esse serviço, por mera conveniência, caso você opte por outro serviço em seu laboratório, não vejo problema algum.

A instalação abaixo se aplica nos dois nós do cluster, ok?

# yum install epel-release -y
# yum install keepalived nginx -y

# apt-get update
# apt-get install keepalived nginx -y

Feita a instalação precisamos ajustar o arquivo de configuração do keepalived para que o serviço tenha declarado qual o endereço IP flutuante (VIP, lembre-se desse cara!) e para saber qual seu papel dentro do cluster, além disso, nele também consta qual o serviço que ele vai monitorar, no nosso laboratório, será o nginx.

No seu servidor mestre, você irá adicionar o arquivo de configuração abaixo. Nesse arquivo consta o nome do seu script de checagem, que pode ser qualquer nome, o script propriamente dito define qual serviço ele ira verificar se esta no ar ou não, o pidof como a maioria já sabe verifica se existem processos daquele serviço pesquisado, caso exista o retorno será sempre 0, caso não encontre, o retorno é diferente de 0 e portanto o cluster promove o escravo, nomeando como mestre e adicionando o IP flutuante nele.

O failover do keepalived trabalha com o protocolo VRRP, um protocolo que trabalha em multicast, onde não é necessário informar quem é mestre e quem é escravo, porque ele vai se basear no estado (estate) que foi definido e no nome que você determinou pra instância VRRP na configuração, aqui no Lab coloquei o nome de VRRP1, porque eu quis, simples.

Outro fator importante, a interface de rede onde será configurado o IP flutuante, esse IP flutuante fica como um IP secundário, então se preocupe que ele não vai remover o IP setado nesta interface de rede. No caso do Red Hat e CentOS em suas versões recentes ele segue padrões parecidos com os BSD’s, adotando esse nome feio pras interfaces de rede, enquanto para o Debian permanece com o padrão antigo (ethX).

Na cláusula virtual_ipaddress é onde é declarado o endereço VIP (Flutuante), o IP a qual será o ponto único de acesso do cliente. E por fim temos a cláusula track_script onde você precisa chamar o vrrp_script que você definiu, onde foi passado os passos que o keepalived ira conferir se o serviço nginx esta no ar.

Por razões de segurança você pode definir critérios de segurança para o protocolo VRRP baseado em autenticação. Nesse modelo adotado estamos seguindo o modelo PASS, que basicamente transita em texto puro a senha, em produção não é recomendável, caso você queira um tipo de autenticação mais eficiente, recomendo a leitura a seguir: http://louwrentius.com/configuring-attacking-and-securing-vrrp-on-linux.html

# vim /etc/keepalived/keepalived.conf
vrrp_script linuxsysadmin {
        script "pidof nginx"
        interval 2
        weight 2
}
 
vrrp_instance VRRP1 {
    state MASTER
    interface enp0s3
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 9999
    }
    virtual_ipaddress {
        10.100.0.135/24
    }
    track_script {
        linuxsysadmin
    }
 
}

# vim /etc/keepalived/keepalived.conf
vrrp_script linuxsysadmin {
        script "pidof nginx"
        interval 2
        weight 2
}
 
vrrp_instance VRRP1 {
    state MASTER
    interface eth0
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 9999
    }
    virtual_ipaddress {
        10.100.0.135/24
    }
    track_script {
        linuxsysadmin
    }
 
}

No escravo configure como no modelo abaixo, basicamente idêntico ao modelo do mestre, com exceção de que o estado aqui ficado definido como BACKUP, ao invés de MASTER.

# vim /etc/keepalived/keepalived.conf
vrrp_script linuxsysadmin {
        script "pidof nginx"
        interval 2
        weight 2
}
 
vrrp_instance VRRP1 {
    state BACKUP
    interface enp0s3
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 9999
    }
    virtual_ipaddress {
        10.100.0.135/24
    }
    track_script {
        linuxsysadmin
    }
 
}

# vim /etc/keepalived/keepalived.conf
vrrp_script linuxsysadmin {
        script "pidof nginx"
        interval 2
        weight 2
}
 
vrrp_instance VRRP1 {
    state BACKUP
    interface eth0
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 9999
    }
    virtual_ipaddress {
        10.100.0.135/24
    }
    track_script {
        linuxsysadmin
    }
 
}

Antes de testar o failover, não se esqueça de incluir os serviços que serão monitorados para subirem durante o boot do sistema operacional.

# systemctl enable keepalived
# systemctl enable nginx
# systemctl start nginx

Nos servidor mestre inicie o serviço do keepalived. Aguarde alguns instantes e confira se o VIP subiu.

# systemctl start keepalived
# echo MASTER > /var/www/html/index.html
# ip addr show
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:ae:d6:54 brd ff:ff:ff:ff:ff:ff
    inet 10.100.0.68/8 brd 10.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.100.0.135/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:feae:d654/64 scope link 
       valid_lft forever preferred_lft forever

# /etc/init.d/keepalived start
# echo MASTER > /var/www/html/index.html
# ip addr show
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:ae:d6:54 brd ff:ff:ff:ff:ff:ff
    inet 10.100.0.68/8 brd 10.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.100.0.135/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:feae:d654/64 scope link 
       valid_lft forever preferred_lft forever

Com o mestre no ar, podemos iniciar o slave e efetuar os testes para validar a nossa alta disponibilidade.

# systemctl start keepalived
# echo SLAVE > /var/www/html/index.html

# /etc/init.d/keepalived restart
# echo SLAVE > /var/www/html/index.html

Em seguida abra seu navegador e acesse o VIP pelo seu navegador, a janela será semelhante a imagem abaixo. Você ra notar que ele esta apontando pro servidor mestre.

Agora faremos o teste propriamente dito, forçaremos o encerramento do processo do serviço nginx. Feito esse procedimento, o keepalived vai entrar no processo de eleição, onde ele precisa promover o servidor escravo (BACKUP) para mestre.

# pkill nginx

Pelos logs do keepalived também é possível acompanhar essa mudança. No serviço mestre execute o tail em messages e será possível verificar que houve falhe, e que ele passa se declarar como backup (escravo).

# tail -f /var/log/messages
Mar  9 14:59:43 master Keepalived_vrrp[5769]: VRRP_Script(linuxsysadmin) failed
Mar  9 14:59:44 master Keepalived_vrrp[5769]: VRRP_Instance(VRRP1) Received higher prio advert
Mar  9 14:59:44 master Keepalived_vrrp[5769]: VRRP_Instance(VRRP1) Entering BACKUP STATE

No servidor escravo também fica evidência de que o servidor corrente foi eleito (promovido) a mestre, devido a indisponibilidade do mestre primário.

# tail -f /var/log/messages
Mar  9 14:59:44 slave Keepalived_vrrp[5238]: VRRP_Instance(VRRP1) forcing a new MASTER election
Mar  9 14:59:45 slave Keepalived_vrrp[5238]: VRRP_Instance(VRRP1) Transition to MASTER STATE
Mar  9 14:59:46 slave Keepalived_vrrp[5238]: VRRP_Instance(VRRP1) Entering MASTER STATE

Essa eleição é feita, porque no keepalived é possível ter mais de um escravo, por isso o keepalived suporta trabalhar com níveis de prioridade, onde ele pode eleger o servidor escravo com maior prioridade.

Bem, acho que de failover é isso, e não tem muito o que falar sobre o assunto. Quem se interessou sobre o assunto, já escrevi um artigo sobre Alta Disponibilidade (Failover) com Heartbeat, dando como exemplo o Zabbix, caso tenha interesse no assunto, recomendo a leitura: http://www.linuxsysadmin.com.br/index.php/2015/08/05/zabbix-em-alta-disponibilidade-com-heartbeat/

Fico por aqui caros amigos e colegas, forte abraço e sucesso nessa empreitada!

See ya!

Nginx: Balanceamento de Carga em Aplicações Web

Como o próprio site do projeto o define:

“O Nginx (Pronuncia correta: Engine X) é um HTTP e um servidor proxy reverso, um servidor proxy de email e um servidor proxy genérico TCP/UDP, escrito originalmente por Igor Sysoev. Por um longo tempo, ele foi executado em muitos sites russos fortemente carregados, incluindo Yandex, Mail.Ru, VK, e Rambler. De acordo com a Netcraft, o nginx como servidor ou proxy esteve presente em 27,90% dos sites mais movimentados em julho de 2016. Aqui estão algumas das histórias de sucesso:

  • Netflix
  • WordPress.com
  • FastMail.FM

1. Introdução ao Nginx

A grosso modo, basicamente o Nginx é o atual concorrente do Apache, sendo um servidor web (http) com demais funcionalidades. O que fazem com que ambos sejam semelhantes, mas tendo cada um sua particularidade, além de cada um ter seu grandioso e respeito espaço no mercado.

O Nginx se tornou popular por ser fácil de configurar e ter um response time significativo. Mas é válido dizer que de forma alguma estou aqui para afirmar que ele é melhor que o Apache, já que respeito muito ambos os projetos.

Neste post iremos esclarecer como configurar o Nginx como Balanceador de Carga para aplicações HTTP, configurando o mesmo para balancear requisições HTTP entre dois nodes (nós).

Caso tenha dúvida sobre como funciona Balanceamento de Carga o conceito pode ser mais esclarecido no respectivo link: http://www.linuxsysadmin.com.br/index.php/2015/08/06/alta-disponibilidade-o-conceito/

2. Instalando o Nginx

Primeiramente vamos instalar e configurar o repositório oficial do Nginx e em seguida instalar o pacote nginx.

Lembrando que damos sempre preferência ao repositório oficial, já que o mesmo possui versões do pacote muito mais atualizada que os pacotes disponibilizados nos repositórios das distribuições.


No CentOS, execute os passos:

# vim /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1
:x!
# yum install nginx


No Debian, execute os passos:

# vim /etc/apt/sources.list.d/nginx.list
deb http://nginx.org/packages/debian/ jessie nginx
deb-src http://nginx.org/packages/debian/ jessie nginx
:X!
# wget http://nginx.org/keys/nginx_signing.key -O /tmp/nginx_signing.key
# apt-key add /tmp/nginx_signing.key
# apt-get update
# apt-get install nginx

3. Configurando o Load balancer

Feita a instalação do Nginx, precisamos configurar o balanceamento de carga no ambiente da seguinte forma:


No CentOS e Debian, execute os passos:

# vim /etc/nginx/conf.d/balancer.conf
# Pool do Load balancer
upstream pool.linuxsysadmin.com.br {
        server 192.168.50.3;
        server 192.168.50.4;
}
 
# Setando as variáveis do cabeçalho HTTP.
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Queue-Start “t=${msec}000”;
 
# Proxy Pass do balanceador
server {
    listen       80;
    server_name  localhost;
 
        location / {
                proxy_pass http://pool.linuxsysadmin.com.br;
        }
}

A diretiva “upstream” aponta o Virtual Host a ser utilizado pelo Balanceador de Carga, dentro os parâmetros “server” indicam os servidores de backend, ou seja, será o nodes utilizados utilizados no cluster.

Abaixo possui os parâmetros proxy_set_header, eles tem a finalidade de trocar os campos do cabeçalho HTTP por variáveis. Mais informações sobre os campos do cabeçalho HTTP podem ser obtidas em https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

E por último a diretiva “server” faz o proxy pass, declarando que o contexto raiz “/” será direcionado para o Virtual Host do Balanceador de Carga.

Feito o procedimento acima, podemos adicionar o nginx no boot do sistema operacional e reiniciar o serviço do Nginx.


No CentOS e Debian, execute os passos:

# systemctl enable nginx
# systemctl restart nginx

Obs: É importante que as máquinas 192.168.50.3 e 192.168.50.4 já esteja no ar e configuradas. No caso eu recomendaria instalar o apache em ambas as maquinas e criar um index.html dentro de /var/www e/ou /var/www/html dependendo da distribuição utilizada. Outro ponto a considerar é que estes endereços podem ser trocados de IP para nome, como por exemplo app01.linuxsysadmin.com.br, app02.linuxysadmin.com.br, etc. Porém é importante que o balanceador de carga esteja resolvendo o nome adequadamente.

4. Validando o Balanceamento de Carga

Edite o seu /etc/hosts e adicione a entrada:

:

# echo -e "IPDOSERVIDORNGINX\tpool.linuxsysadmin.com.br" > /etc/hosts

Abra o seu navegador e acesse http://pool.linuxsysadmin.com.br:

5. Métodos de Balanceamento de Carga

O Nginx possui três métodos de balanceamento de carga suportados, sendo eles:

  1. round-robin — As requisições são distribuídas igualmente entre os servidores.
  2. least-connected — O próximo pedido é sempre atribuído ao servidor com o menor número de conexões ativas.
  3. ip-hash — A função ip_hash é usada para determinar qual servidor deve ser selecionado para o próximo pedido (com base no endereço IP do cliente), tendo uma sessão persistente.

Muitas vezes é visto administradores recomendando desenvolvedores a modificar a aplicação para fazer uso de Memcache ou Redis para manter a sessão entre os nós do cluster, entre outros modelos.
De repente estes modelos apresentados acima podem lhe atender bem, sem necessidade de modificações extras no cenário.

Estes métodos devem ser adotados de acordo com o melhor modelo para sua aplicação.

6. Round Robin

Round Robin é o modelo de balanceamento de carga padrão adotado pelo Nginx. Caso o método não seja especificado ele sempre assume o método Round Robin. No caso, o modelo que estamos usando neste cenário é o método Round Robin.

Note no navegador que conforme é feito o refresh da página ora ele acesse 192.168.50.3 ora aparece 192.168.50.4, porque ele sempre vai distribuir a requisição igualmente entre cada nó.

7. Least Connected

O Least Connected como informado acima direciona a próxima requisição sempre para o nó com o menor número de conexões.

Para configurar o seu balanceamento de carga com este método, basta adicionar o parâmetro “least_conn” dentro da diretiva upstream. Por exemplo:


No CentOS e Debian, execute os passos:

# vim /etc/nginx/conf.d/balancer.conf
(...)
upstream pool.linuxsysadmin.com.br {
        least_conn;
        server 192.168.50.3;
        server 192.168.50.4;
}
(...)

Reinicie o serviço do Nginx para aplicar a mudança.


No CentOS e Debian, execute os passos:

# systemctl restart nginx

Para validar este método, abra seu navegador e acesse pool.linuxsysadmin.com.br e faça um refresh da página para entender de forma prática como ele aplica este modelo.

8. IP Hash

O IP Hash como dito acima direciona a requisição sempre sempre para o mesmo nó, baseado no IP de origem. Ou seja, se a estação 192.168.50.10 acessar o balanceador pelo navegador, supondo que o nginx jogou essa requisição para o primeiro nó, ele sempre vai direcionar a requisição deste cliente para o primeiro nó.
Para configurar o seu balanceamento de carga com este método, basta adicionar o parâmetro “ip_hash” dentro da diretiva upstream. Por exemplo:


No CentOS e Debian, execute os passos:

# vim /etc/nginx/conf.d/balancer.conf
(...)
upstream pool.linuxsysadmin.com.br {
        ip_hash;
        server 192.168.50.3;
        server 192.168.50.4;
}
(...)

Reinicie o serviço do Nginx para aplicar a mudança.


No CentOS e Debian, execute os passos:

# systemctl restart nginx

Para validar este método, abra seu navegador e acesse pool.linuxsysadmin.com.br e faça um refresh da página para entender de forma prática como ele aplica este modelo. Note que ele a requisição sempre é enviada para o mesmo nó.

9. Conclusão

O Balanceamento de Carga do Nginx como visto é muito simples de se configurar. Além disso, o Nginx vem crescendo cada vez mais, cada dia ganhando mais e mais espaço no mercado, sendo adotado por diversas empresas e nos mais variados ambientes.

Por isso espero que este post lhe seja útil e que te ajude a compreender de forma fácil como funciona o balanceamento de carga de aplicações web.

Mais informações sobre o Nginx podem ser obtidas diretamente em sua documentação oficial: https://nginx.org/en/docs/

O que é Alta Disponibilidade?

O conceito de Alta Disponibilidade surgiu devido a grande demanda de serviços de TI integrados ao negócio, quanto mais o serviço ou aplicação for necessária ao negócio e sua indisponibilidade impactar diretamente nos lucros da empresa, maior será a necessidade de ampliar a disponibilidade dos servidores, aplicações, etc.

A Alta Disponibilidade possui dois modelos de arquiteturas popularmente usados, sendo um deles o modo passivo/ativo. Usado quando se tem dois servidores, sendo um dos nodes o mestre o outro nó o escravo, quando o nó mestre fica indisponível o nó escravo assume o novo papel de mestre, ele é promovido a mestre. Conforme a imagem abaixo.

Tecnicamente este modelo de arquitetura consiste basicamente de três endereços IPs, sendo os dois utilizados nos dois nodes do cluster e o endereço VIP (Virtual IP), o VIP é o endereço de rede que deve ser disponibilizado para os usuários finais, pois quando o mestre ficar indisponível o escravo vai assumir o endereço VIP.

Por exemplo, imagine que um Analista esteja trabalhando durante o horário comercial, das 9hs as 18hs, e o departamento dele atua 24×7, o Analista que estiver escalonado como plantonista, passa ser o escravo (slave), caso o analista do horário comercial (master) estiver indisponível, o escravo é promovido a master e atuar nos chamados as quais o Analista do horário comercial não poder atuar.

O outro método popularmente utilizado é o modelo ativo/ativo, também conhecido como Load Balancing , onde o cluster possui diversos nodes, formando o que é conhecido como “pool”, nesse cluster todos os nodes são mestres, no entanto a carga é balanceada entre todos os nodes. Entenda que node em termos de alta disponibilidade refere-se a servidores. E cada requisição é direcionada a um nó diferente afim de aliviar a carga e distribui-la para que sua aplicação ou serviço tenha ganho de desempenho e produtividade, a grande vantagem do balanceamento de carga é o escalonamento horizontal do seu cluster, quando a aplicação crescer e a arquitetura sofrer demanda, basta adicionar novos nodes no cluster. Conforme o modelo abaixo:

Tecnicamente no Load Balancing os usuários finais da aplicação e/ou serviço não enxergam os servidores que se encontram no “Backend”, os nodes do cluster, apenas o servidor que faz o balanceamento, também conhecido como Balancer (Balanceador) ou Diretor. Inclusive o balanceador é um dos SPOF (Single Point of Failure) dessa arquitetura de alta disponibilidade, o SPOF significa que esse é o único ponto de falha, ou seja, se o balancer ficar indisponível, toda a arquitetura se torna indisponível impactando diretamente o usuário final. Nesse tipo de circunstância é possível aplicar o modelo passivo/ativo no balanceador, assim caso o balanceador mestre ficar indisponível, o balanceador escravo é promovido a mestre e a arquitetura permanece disponível e sem perda significativa para o usuário final. Porém como eu afirmei acima, é UM dos SPOFs, mas não o único, se observarem bem a arquitetura, notarão que o Banco de Dados esta isolado em outro servidor, por tanto se este ficar indisponível, toda arquitetura também falha. Sendo assim é necessário também aplicar algum modelo de alta disponibilidade. Porém se tratando de alta disponibilidade em Banco de Dados, o assunto é bastante delicado, já que se trata de dados, então a indisponibilidade do mestre e a virada do nó escravo para mestre pode ocasionar em perdas transacionais, por exemplo, e em alguns SGBDRs (Sistema de Gerenciamento de Banco de Dados Relacionais) não é possível nativamente construir bancos de dados em modelos master-to-master, onde os dois aceitam escritas e são replicados entre os nodes do cluster, se tornando os dois nodes replicas fiéis um do outro. Normalmente em se tratando de banco de dados o escravo nada mais é do que uma replica com permissão apenas de leitura, não podendo ser escrito diretamente nele, e o chaveamento se torna manual, porém é importante deixar claro que isso não é uma regra, pode sim ter o chaveamento automático dependendo da tecnologia utilizada para intermediar essa situação ou mesmo se o SGBDR tem esse suporte nativo.

Exemplo do conceito de balanceamento, quando um Gerente de TI recebe muitos chamados, a primeira coisa que ele faz é distribuir esses chamados a todos os analistas que estiverem ociosos, a fim de distribuir a carga de trabalho, fazendo uma analogia, o Gerente de TI é o Balanceador, e os analistas são os Backend, são os membros do Cluster. Quando o Gestor de TI recebe uma maior demanda de trabalho ele necessita contratar mais mão de obra, em se tratando de uma arquitetura balanceada não se difere muito, novos membros podem ser adicionados ao cluster, construindo um escalonamento horizontal, tornando uma arquitetura mais ampla.

Estes modelos devem ser aplicados de acordo com determinadas circunstâncias que sempre devem ser avaliadas pelo Arquiteto de Soluções do projeto ou pelo Administrador de Sistemas (SysAdmin), prevendo os possíveis pontos únicos de falha e as formas de contornar a situação construindo um ambiente totalmente tolerante a falhas. Construir ambientes alto disponíveis hoje já é uma realidade e vista com bons olhos dentro das empresas de diversos segmentos ou setores de tecnologias, onde os profissionais com esses conhecimentos e capacidades técnicas para desenhar a solução e aplica-las são muito bem remunerados e considerado um enorme diferencial perante aos seus colegas.

Na categoria sobre Alta Disponibilidade veremos na prática como construir arquiteturas de Alta Disponibilidades eficiente através de soluções FOSS (Free & Open Source Solution), como Heartbeat, Pacemaker, Corosync, DRBD, lvs, RHCS (Red Hat Cluster Suite), etc.

Zabbix em Alta Disponibilidade com Heartbeat

Olá pessoal,

Neste artigo pretendo explicar como construir uma infraestrutura no Zabbix compatível com Alta Disponibilidade através do pacote Heartbeat.  No final do artigo teremos uma infraestrutura altamente capacitada a suportar a alta disponibilidade do nosso ambiente de monitoramento.

1. O Cenário

Para este cenário será necessário três servidores, sendo um o servidor de banco de dados e dois para o Zabbix. As configurações podem ser as mínimas possíveis por se tratar de um ambiente de laboratório:

  • srvdbzbx01: 1 Proc, 512MB de RAM e disco de 8GB
  • srvzbxnode01: 1 Proc, 512MB de RAM e disco de 8GB
  • srvzbxnode02: 1 Proc, 512MB de RAM e disco de 8GB

Outros fatores IMPORTANTES:

  • O endereço IP do VIP, deve estar disponível na rede.
  • O endereço IP VIP não deve ser configurado nas configurações de Rede.
  • Quem vai fazer as configurações de rede do endereço VIP é o heartbeat!
  • Recomendável haver duas interfaces de rede no mínimo, por exemplo:
  • eth1: LAN, ou seja, diretamente na rede.
  • eth0: Conectada diretamente ao outro nó com cabo Crossover.

Ficando como no modelo abaixo (Lembrando que não é obrigatório o uso de cabo Crossover, mas garante comunicação direta entre os dois nós do Cluster):


Levarei em consideração que o seu zabbix já esteja instalado e configurado, totalmente funcional e com a base de dados isolada em OUTRO servidor. Se você não viu o modo de instalação do servidor Zabbix, recomendo a leitura sobre em Instalação Zabbix Fácil e Prático.

A arquitetura desse laboratório será semelhante a estrutura desenhada a baixo:

Para esta solução usaremos o pacote heartbeat, hoje já obsoleto e descontinuado, substituído pelo pacote Pacemaker, no entanto o Heartbeat não deixa a desejar, atende bem os principais requisitos de Alta Disponibilidade, o que se enquadra eficiente para o tipo de arquitetura a qual pretendemos montar. Num futuro não muito distante podemos abordar aqui no site técnicas de alta disponibilidade baseadas no Pacemaker.

Como sempre a minha ideia é sempre construir artigos baseadas em multi-distribuição, ou seja, abordar as duas principais distribuições Linux no mercado, sendo elas RHEL (Red Hat Enterprise Linux) e Debian, por serem as mais utilizadas, no entanto distribuições como CentOS, Fedoras, Ubuntu, Mint, entre outras se enquadram nesse quesito por serem baseadas nessas respectivas distribuições comentadas acima.

2. Instalando o Heartbeat.

Primeiramente precisamos baixar os pacotes que serão necessário para nossa solução de HA (High Availability):

No CentOS (Red Hat) 6, executando nos servidores mestre e escravo:

1
2
3
4
5
# yum update
# wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# rpm -ivh epel-release-6-8.noarch.rpm
# yum install heartbeat
# chkconfig heartbeat on

No Red Hat/CentOS não tem disponível por default o pacote heartbeat, apenas no repositório EPEL (Extra Packages for Enterprise Linux).
O único pacote relacionado a HA por padrão no Red Hat (CentOS) é o pacote “piranha”, que é RHCS (Red Hat Cluster Suite).
Outro fator importante: No Red Hat/CentOS 7 não esta mais disponível o pacote heartbeat nos repositórios, conforme avisado acima, o pacote heartbeat esta descontinuado, por isso não é novidade esse comportamento das versões mais recentes das distribuições.


No Debian, executando nos servidores mestre e escravo:

1
2
# apt-get upgrade
# apt-get install heartbeat

3. Preparando o ambiente do Zabbix e o Apache para o Heartbeat

Após a instalação do pacote heartbeat, vamos precisar desabilitar o serviço do zabbix-server e o serviço do apache do boot, pois quem vai gerenciar o “start” dos serviços pertencentes ao cluster é o Heartbeat e não o Sistema Operacional.  Quanto ao upgrade, é para realizar atualização de pacotes desatualizados, afim de evitar conflitos ou dependências. Não confunda com o update, que apenas atualiza a base de repositórios no Debian.


No Red Hat, executando nos servidores mestre e escravo:

1
2
# chkconfig zabbix-server off
# chkconfig httpd off


No Debian, executando nos servidores mestre e escravo:

1
2
# update-rc.d -f zabbix-server remove
# update-rc.d -f apache2 remove

Após desabilitar os serviços da inicialização do boot. Precisamos copiar os arquivos de inicialização que se encontram dentro de /etc/init.d/ para dentro de /etc/ha.d/resource.d/.


No Red Hat, executando nos servidores mestre e escravo:

1
2
# cp /etc/init.d/httpd /etc/ha.d/resource.d/
# cp /etc/init.d/zabbix-server /etc/ha.d/resource.d/


No Debian, executando nos servidores mestre e escravo:

1
2
# cp /etc/init.d/apache2 /etc/ha.d/resource.d/
# cp /etc/init.d/zabbix-server /etc/ha.d/resource.d/

 

Para o heartbeat, todos os scripts que estiverem armazenados dentro de /etc/ha.d/resource.d/ são recursos. Recursos nada mais são do que utilitários de inicialização do heartbeat para executar um serviço após o chaveamento entre os nodes do cluster.

Precisamos alterar os nomes no /etc/hosts para fazer as referências dos nomes de cada nó do cluster que serão usados pelo heartbeat para identificar.


No Red Hat e Debian, somente no Mestre:

1
2
3
4
5
# vim /etc/hosts
127.0.0.1   localhost
127.0.0.1   srvzbxnode01.linuxsysadmin.com.br srvzbxnode01
IP_DO_SLAVE srvzbxnode02.linuxsysadmin.com.br srvzbxnode02
:x!


No Red Hat e Debian, somente no Escravo:

1
2
3
4
5
# vim /etc/hosts
127.0.0.1    localhost
127.0.0.1    srvzbxnode02.linuxsysadmin.com.br srvzbxnode02
IP_DO_MASTER srvzbxnode01.linuxsysadmin.com.br srvzbxnode01
:x!

4. Configurando os recursos do Heartbeat

Como já alterarmos os nomes dos nodes do cluster e também já adicionamos os scripts de inicialização no diretório de recursos do heartbeat (/etc/ha.d/resource.d/). Precisamos editar o arquivo chamado haresources, dentro de /etc/ha.d/. No entanto pode ser que este arquivinho não venha por padrão em algumas distribuições, entretanto, isso é normal, cria-lo do zero é muito simples.


No Red Hat, somente no Mestre:

1
2
3
# vim /etc/ha.d/haresources
srvzbxnode01    IPaddr::192.168.100.15/24/eth0 zabbix-server httpd
:x!


No Debian, somente no Mestre:

1
2
3
# vim /etc/ha.d/haresources
srvzbxnode01    IPaddr::192.168.100.15/24/eth0 zabbix-server apache2
:x!


No Red Hat, somente no Escravo:

1
2
3
# vim /etc/ha.d/haresources
srvzbxnode02    IPaddr::192.168.100.15/24/eth0 zabbix-server httpd
:x!


No Debian, somente no Escravo:

1
2
3
# vim /etc/ha.d/haresources
srvzbxnode02    IPaddr::192.168.100.15/24/eth0 zabbix-server apache2
:x!

5. Ajustando o arquivo de configuração do Heartbeat

Após informarmos o nó do cluster e o recursos que devem ser usados durante o chaveamento. Precisamos configurar o arquivo ha.cf, existente dentro de /etc/ha.d/, este “carinha” é o principal arquivo de configuração do heartbeat.


No Red Hat, no Mestre e Escravo:

# vim /etc/ha.d/ha.cf
logfile	/var/log/ha-log # Log do heartbeat.
logfacility local0 # Facility que o log vai trabalhar no padrão syslog.
keepalive 2 # Tempo em segundos de verificação dos nodes.
deadtime 30 # Tempo mínimo para determinar que o nó esta indisponível.
bcast eth0 
auto_failback off # Quando ativado (on) o cluster retorna ao nó primário (mestre).
node srvzbxnode01 # São os nodes do cluster.
node srvzbxnode02 # São os nodes do cluster.
compression bz2 # Compressão de dados
compression_threshold 2
:x!


No Debian, no Mestre e Escravo:

# vim /etc/ha.d/ha.cf
logfile	/var/log/ha-log # Log do heartbeat.
logfacility local0 # Facility que o log vai trabalhar no padrão syslog.
keepalive 2 # Tempo em segundos de verificação dos nodes.
deadtime 30 # Tempo mínimo para determinar que o nó esta indisponível.
bcast eth0
auto_failback off # Quando ativado (on) o cluster retorna ao nó primário (mestre).
node srvzbxnode01 # São os nodes do cluster.
node srvzbxnode02 # São os nodes do cluster.
compression bz2 # Compressão de dados
compression_threshold 2
:x!

6. Configurando as chaves de autenticação do Cluster

Após esta etapa é necessário configurar as chaves de autenticação usadas pelo Heartbeat. Usadas para confirmar que o hosts a qual esta tentando conversar é um membro (node) oficial do cluster.


No Red Hat e Debian, no Mestre e Escravo:

1
2
3
4
5
# vim /etc/ha.d/authkeys
auth 3
3 md5 FraseUsadaComoPalavraPasseNoClusterCriptografadaEmAlgoritmoMD5
:x!
# chmod 600 /etc/ha.d/authkeys

 

Essa frase usada no /etc/ha.d/authkeys deve ser a MESMA usada nos dois nodes do cluster, ou seja, no mestre e no escravo.

Após a criação da chave de autenticação, precisamos reiniciar o serviço do heartbeat para efetuar todas as alterações realizadas nas configuração do heartbeat.
Mas antes é necessário garantir que os serviços do apache e do zabbix estejam parados em ambos os servidores. Pois assim podemos fazer o teste com maior precisão.


No Red Hat e Debian, primeiramente no Mestre e após alguns segundos execute o mesmo no Escravo:

1
# /etc/init.d/heartbeat restart

7. Preparando o Zabbix para o ambiente de Alta Disponibilidade (HA)

Antes de testarmos a alta disponibilidade do Heartbeat, precisamos garantir que o Zabbix esta configurado corretamente.


No Red Hat e Debian:

1
2
3
4
5
6
# grep ^DB /etc/zabbix/zabbix_server.conf
# Caso o seu servidor de banco seja em Alta Disponibilidade, é necessário informar o endereço VIP.
DBHost=srvdbzbx01
DBName=zabbixdb
DBUser=zbxuser
DBPassword=SenhaDozbxuser

Verificado que as configurações estão corretas. E após reiniciar o serviço do heartbeat. Execute somente no servidor mestre o comando abaixo, para confirmar que o endereço VIP foi ativado:


No Red Hat e Debian, somente no MESTRE:

1
2
3
4
5
6
7
# ip a show eth1
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:62:52:7b brd ff:ff:ff:ff:ff:ff
    inet 10.100.0.52/8 brd 10.255.255.255 scope global eth0
    inet VIP/8 brd 10.255.255.255 scope global secondary eth0
    inet6 fe80::a00:27ff:fe62:527b/64 scope link 
       valid_lft forever preferred_lft forever

A linha “inet VIP/8 brd 10.255.255.255 scope global secondary eth0” corresponde a configuração IP do endereço VIP. Que no caso eu omite apenas para ficar didático.

Em seguida, abra o navegador e acesse o endereço IP do seu VIP, para acessar o Frontend do Zabbix.

7. Testando o chaveamento do Cluster

Agora para chavear para o nó escravo, abra os terminais dos dois servidores, no mestre para o serviço do heartbeat:


No Red Hat e Debian, desligue somente o MESTRE:

1
# shutdown -h now

No nó escravo, observe o log se aparece informações semelhantes a essas:

No Red Hat e Debian, somente no ESCRAVO:

1
2
3
4
5
6
7
8
# tail -f /var/log/ha-log
(...)
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/IPaddr 192.168.100.15/24/eth0 start
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/httpd  start
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/zabbix-server  start
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: WARN: node srvzbxnode01: is dead
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: info: Cancelling pending standby operation
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: info: Dead node srvzbxnode01 gave up resources.

Ou


No Red Hat e Debian, somente no ESCRAVO:

1
2
3
4
5
6
7
8
# tail -f /var/log/ha-log
(...)
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/IPaddr 192.168.100.15/24/eth0 start
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/apache2  start
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/zabbix-server  start
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: WARN: node srvzbxnode01: is dead
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: info: Cancelling pending standby operation
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: info: Dead node srvzbxnode01 gave up resources.

Aguarde alguns instantes, abra novamente o navegador e acesse o endereço IP do seu VIP, para acessar o Frontend do Zabbix, agora disponível através do segundo nó do cluster.

8. Melhorando o nível de Alta Disponibilidade

Observação importante: O heartbeat gerencia apenas a nível da indisponibilidade do host, ou seja, se houver a parada apenas do serviço zabbix-server ou do apache, o cluster permanece no mesmo nó, para o heartbeat essa parada é irrelevante. No entanto sua alta disponibilidade já esta pronta, porém não adequada aos melhores padrões.

8.1 Instalando o pacote mon

Para essa finalidade de contornar essa fragilidade do Heartbeat, vamos instalar um pacote chamado mon, que será o responsável por monitorar os serviços do sistema e caso tenha parada dos serviços, como apache (httpd) ou zabbix_server, o mon vai parar o heartbeat, fazendo com que o escravo seja promovido a mestre.

Instale o pacote mon:

Execute no Red Hat, tanto no mestre quanto no escravo:

1
# yum install mon

Execute no Debian, tanto no mestre quanto no escravo:

1
# apt-get install mon

Após a instalação é necessário a instalação do pacote sudo, caso o seu SO esteja sem o sudo instalado, instale o mesmo através dos comandos abaixo:

Execute somente no Debian, tanto no mestre quanto no escravo:

1
# apt-get install sudo

Após a instalação do sudo, é necessário ajustarmos o arquivo de configuração do mon, o mon.cf:

8.2 Configurando o mon

 

Execute no Red Hat, tanto no mestre quanto no escravo:

# vim /etc/mon/mon.cf
# Se o seu centos não for 64, deixe como /usr/lib/mon/alert.d
alertdir                = /usr/lib64/mon/alert.d
# Se o seu centos não for 64, deixe como /usr/lib/mon/mon.d
mondir                  = /usr/lib64/mon/mon.d
maxprocs                = 20
histlength              = 100
randstart               = 60s
dtlogging               = yes
dtlogfile               = dtlog
 
hostgroup localhost
localhost
 
watch localhost
        service http
                description HTTP service
                interval 1m
                monitor http.monitor -p 80 -t 10 -o localhost
                period  wd {Mon-Mon}
                        alert heartbeat.alert
        service zabbix
                description Zabbix Server service
                interval 1m
                monitor zabbix.monitor zabbix_server 10051
                period  wd {Mon-Mon}
                        alert heartbeat.alert
:x!

Execute no Debian, tanto no mestre quanto no escravo:

# vim /etc/mon/mon.cf
alertdir		= /usr/lib/mon/alert.d
mondir			= /usr/lib/mon/mon.d
maxprocs		= 20
histlength		= 100
randstart		= 60s
dtlogging		= yes
dtlogfile		= dtlog
 
hostgroup localhost
localhost
 
watch localhost
	service http
		description HTTP service
		interval 1m
		monitor http.monitor -p 80 -t 10 -o localhost
		period  wd {Mon-Mon}
			alert heartbeat.alert
	service zabbix
		description Zabbix Server service
		interval 1m
		monitor zabbix.monitor zabbix_server 10051
		period  wd {Mon-Mon}
			alert heartbeat.alert
:x!

8.3 Entendendo o conceito do mon

Conceitos Básicos sobre o Mon
O mon tem a finalidade de monitorar serviços, protocolo entre outros recursos através de rotinas em intervalos definidos pelo administrador da ferramenta. E também tomar ações, como enviar e-mail, reiniciar o serviço, alertar o administrador do sistema, e etc. quando o determinado serviço ou protocolo estiver indisponível. O mon possui fácil integração com diversas ferramentas, principalmente com o Heartbeat, pacote que estamos utilizando neste material.

O mon possui dois diretórios que se encontram dentro de /urs/lib[64]/mon, que são fundamentais:

  • /usr/lib/mon/mon.d/ – Diretório que contém os scripts que fazem a rotina de verificação de disponibilidade do serviço monitorado.
  • /usr/lib/mon/alert.d – Diretório responsável pelos scripts de alerta, caso o monitoramento aponte a indisponibilidade de um determinado serviço.

A sintaxe básico do principal arquivo de configuração do mon, mon.cf:
Define o grupo de hosts, pois todo host monitorado, deve pertencer ao um grupo, em baixo é definido que o grupo localhost possui um host, chamado localhost. (Nada mais que o próprio loopback)

hostgroup localhost
localhost

O watch é onde iniciado o bloco de serviços as quais serão monitorados pelo respectivo host, no caso localhost, definido no grupo acima.

watch localhost

O parâmetro service, é simbólico, nada verdade ele é só a referência para um serviço, para melhor organizar o arquivo.

service zabbix
		description Zabbix Server service # Descrição sobre o serviço monitorado
		interval 1m # Intervalo de monitoramento
		monitor zabbix.monitor zabbix_server 10051 # Script de monitoramento e os parâmetros passados.
		period  wd {Mon-Mon} # Período na semana que será feito o alerta.
			alert heartbeat.alert # Script de alerta, acionado em caso de indisponibilidade do serviço

8.4 Criando o script de monitoramento.

Voltando, após o entendimento básico sobre o mon e o ajuste correto no arquivo de configuração, precisamos configurar o restante, crie o arquivo zabbix.monitor dentro de /usr/lib/mon/mon.d. A finalidade desse script é monitorar se o serviço zabbix_server esta ativo no host.

Execute no Red Hat, tanto no mestre quanto no escravo:

# vim /usr/lib64/mon/mon.d/zabbix.monitor
ou
# vim /usr/lib/mon/mon.d/zabbix.monitor
#!/bin/bash
# zabbix.monitor é um script desenvolvido para o uso do Zabbix em HA com Heartbeat e o pacote mon.
# Autor: Elvis Suffi Pompeu <elvis.suffipompeu@hotmail.com>
# Seg Ago 24 10:35:44 BRT 2015
COUNT_SERVICE="$(/bin/ps -ef | /bin/grep ${1} | /bin/grep -v grep | /usr/bin/wc -l)"
COUNT_PORT="$(/bin/netstat -ntl | /bin/grep "${2}" | /bin/grep -v grep | /usr/bin/wc -l)"
 
if [ ${COUNT_SERVICE} -eq 0 ]; then
 
        # Serviço DOWN
        exit 1
 
elif [ ${COUNT_PORT} -eq 0 ]; then
 
        # Serviço DOWN
        exit 2
 
else
 
        # Serviço UP (OK)
        exit 0
 
fi
:x!
# chmod +x /usr/lib64/mon/mon.d/zabbix.monitor 
ou
# chmod +x /usr/lib/mon/mon.d/zabbix.monitor

Execute no Debian, tanto no mestre quanto no escravo:

# vim /usr/lib/mon/mon.d/zabbix.monitor
#!/bin/bash
# zabbix.monitor é um script desenvolvido para o uso do Zabbix em HA com Heartbeat e o pacote mon.
# Autor: Elvis Suffi Pompeu <elvis.suffipompeu@hotmail.com>
# Seg Ago 24 10:35:44 BRT 2015
COUNT_SERVICE="$(/bin/ps -ef | /bin/grep ${1} | /bin/grep -v grep | /usr/bin/wc -l)"
COUNT_PORT="$(/bin/netstat -ntl | /bin/grep "${2}" | /bin/grep -v grep | /usr/bin/wc -l)"
 
if [ ${COUNT_SERVICE} -eq 0 ]; then
 
        # Serviço DOWN
        exit 1
 
elif [ ${COUNT_PORT} -eq 0 ]; then
 
        # Serviço DOWN
        exit 2
 
else
 
        # Serviço UP (OK)
        exit 0
 
fi
:x!
# chmod +x /usr/lib/mon/mon.d/zabbix.monitor

8.5 Criando o script de Alerta.

Agora precisamos configurar o script de alerta, que no caso sera acionado quando for detectado a indisponibilidade dos serviços, o mesmo tem a função de “parar” o heartbeat, já que com a indisponibilidade do heartbeat, é feito o chaveamento para o segundo nó do cluster.

Execute no Red Hat, tanto no mestre quanto no escravo:

# vim /usr/lib64/mon/alert.d/heartbeat.alert 
ou
# vim /usr/lib/mon/alert.d/heartbeat.alert 
#!/usr/bin/perl
#
# Shutdown heartbeat
# derived from Jim Trocki's alert.template
#
# Jim Trocki, trockij@transmeta.com
# Sandro Poppi, spoppi@gmx.de
#
#    Copyright (C) 1998, Jim Trocki
#                  2001, Sandro Poppi
#
#    This program is free software; you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation; either version 2 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program; if not, write to the Free Software
#    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#
use Getopt::Std;
getopts ("s:g:h:t:l:u");
# the first line is summary information, adequate to send to a pager
# or email subject line
#
#
# the following lines normally contain more detailed information,
# but this is monitor-dependent
#
# see the "Alert Programs" section in mon(1) for an explanation
# of the options that are passed to the monitor script.
#
$summary=;
chomp $summary;
 
$t = localtime($opt_t);
($wday,$mon,$day,$tm) = split (/\s+/, $t);
 
print <<EOF;
 
Alert for group $opt_g, service $opt_s
EOF
 
print "This alert was sent because service was restored\n"
    if ($opt_u);
 
print <<EOF;
This happened on $wday $mon $day $tm
Summary information: $summary
Arguments passed to this script: @ARGV
Detailed information follows:
 
EOF
 
# shutdown heartbeat
system ("/etc/init.d/heartbeat stop");
:x!
# chmod +x /usr/lib64/mon/alert.d/heartbeat.alert
ou
# chmod +x /usr/lib/mon/alert.d/heartbeat.alert

Execute no Debian, tanto no mestre quanto no escravo:

# vim /usr/lib/mon/alert.d/heartbeat.alert 
#!/usr/bin/perl
#
# Shutdown heartbeat
# derived from Jim Trocki's alert.template
#
# Jim Trocki, trockij@transmeta.com
# Sandro Poppi, spoppi@gmx.de
#
#    Copyright (C) 1998, Jim Trocki
#                  2001, Sandro Poppi
#
#    This program is free software; you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation; either version 2 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program; if not, write to the Free Software
#    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#
use Getopt::Std;
getopts ("s:g:h:t:l:u");
# the first line is summary information, adequate to send to a pager
# or email subject line
#
#
# the following lines normally contain more detailed information,
# but this is monitor-dependent
#
# see the "Alert Programs" section in mon(1) for an explanation
# of the options that are passed to the monitor script.
#
$summary=;
chomp $summary;
 
$t = localtime($opt_t);
($wday,$mon,$day,$tm) = split (/\s+/, $t);
 
print <<EOF;
 
Alert for group $opt_g, service $opt_s
EOF
 
print "This alert was sent because service was restored\n"
    if ($opt_u);
 
print <<EOF;
This happened on $wday $mon $day $tm
Summary information: $summary
Arguments passed to this script: @ARGV
Detailed information follows:
 
EOF
 
# shutdown heartbeat
system ("sudo /etc/init.d/heartbeat stop");
:x!
# chmod +x /usr/lib/mon/alert.d/heartbeat.alert
# chown mon. /usr/lib/mon/alert.d/heartbeat.alert

Somente no Debian havíamos instalado o sudo, porque no Red Hat/CentOS o mon roda com o usuário root, e não sob o usuário do seu daemon (serviço).
Já no Debian o mon, roda sob o usuário mon, por isso precisamos do sudo para criar as regras liberando o usuário mon de executar o stop (parada) do heartbeat, já que quem gerencia e tem permissão, é somente o root.

Execute somente no Debian, tanto no mestre quanto no escravo, adicione somente essa linha abaixo:

1
2
3
# vim /etc/sudoers
mon     ALL=NOPASSWD:/etc/init.d/heartbeat stop
:x!

8.6 Testando as configurações do mon

 

Execute no Red Hat, tanto no mestre quanto no escravo:

# service mon restart
Desligando System Monitoring daemon (mon):                 [  OK  ]
Iniciando System Monitoring daemon (mon):                  [  OK  ]
# monshow
 
       server: localhost
       time: Mon Aug 24 14:59:58 2015
       state: scheduler running
 
All systems OK

Execute no Debian, tanto no mestre quanto no escravo:

# service mon restart
[ ok ] Restarting mon daemon: mon.
# monshow
 
      server: localhost
      time: Mon Aug 24 14:59:59 2015
      state: scheduler running
 
  GROUP           SERVICE      STATUS      LAST       NEXT       ALERTS SUMMARY
R localhost       http         -           30s        30s        none
R localhost       zabbix       -           46s        14s        none
 
Nothing is disabled
:x!

Agora vamos testar, a parada dos serviços para melhor compreensão sobre o serviço mon.

Execute em ambas as distribuições os seguinte comandos, para pararmos o serviço do zabbix e verificar se o mon detectou sua parada e acionou o alerta:

1
2
3
4
5
6
7
8
 # /etc/ha.d/resource.d/zabbix-server stop
# watch -n1 monshow
(...) # Aguarde alguns instantes, até aparecer algo como a mensagem abaixo:
R localhost	  zabbix       FAIL        47s        13s        5	(NO SUMMARY)
ou
  GROUP           SERVICE      STATUS      LAST       NEXT       ALERTS SUMMARY
R localhost       http         -           51s        8s         1      localhost
R localhost       zabbix       FAIL        7s         52s        7      (NO SUMMARY)

Para realizar o teste de forma eficaz:

Execute no Red Hat, tanto no mestre quanto no escravo:

# /usr/lib64/mon/mon.d/zabbix.monitor zabbix_server 10051; echo $?
0
# ps -ef | grep heartbeat
root      1361     1 86 12:19 ?        02:32:06 heartbeat: master control process
root      1373  1361  0 12:19 ?        00:00:00 heartbeat: FIFO reader        
root      1374  1361  0 12:19 ?        00:00:14 heartbeat: write: bcast eth0  
root      1375  1361  0 12:19 ?        00:00:08 heartbeat: read: bcast eth0
(...)
# /usr/lib64/mon/alert.d/heartbeat.alert
# ps -ef | grep heartbeat
root      6104  3958  0 15:14 pts/0    00:00:00 grep heartbeat

Execute no Debian, tanto no mestre quanto no escravo:

# /usr/lib64/mon/mon.d/zabbix.monitor zabbix_server 10051; echo $?
0
# ps -ef | grep heartbeat
root      1361     1 86 12:19 ?        02:32:06 heartbeat: master control process
root      1373  1361  0 12:19 ?        00:00:00 heartbeat: FIFO reader        
root      1374  1361  0 12:19 ?        00:00:14 heartbeat: write: bcast eth0  
root      1375  1361  0 12:19 ?        00:00:08 heartbeat: read: bcast eth0
(...)
# chsh -s /bin/bash mon
# su - mon
$ sudo /usr/lib64/mon/alert.d/heartbeat.alert
$ exit
# ps -ef | grep heartbeat
root      6104  3958  0 15:14 pts/0    00:00:00 grep heartbeat

Se tudo ocorreu nos conformes, sua alta disponibilidade no Zabbix já esta funcional. Agora faça os testes parando esses serviços e verifique se o chaveamento do Heartbeat esta sendo promovido com a parada deles, conforme definido para a responsabilidade do mon gerenciar.

9. Conclusão

Bem espero de coração que este “how to” lhe seja útil. Forte abraço e sucesso! 🙂
Sinta-se a vontade para responder e até mesmo corrigir possíveis erros que possam ter surgido durante a escrita do material. Grato pela atenção!