Os Servidores Web são componentes essenciais em uma rede, onde disponibilizam uma infinidade de serviços, no entanto, são dispositivos eletrônicos e estão sujeitos a falhas, tanto físicas quanto lógicas.

Os responsáveis pelo gerenciamento dos servidores utilizam uma gama de recursos para aumentar e garantir a disponibilidade de acesso aos serviços disponibilizados, como Nobreaks, conexões de rede redundantes, entre outras soluções, mas uma falha pode causar enormes prejuízos e perda da credibilidade de qualquer setor.

Os fabricantes dos equipamentos dedicam uma atenção especial no desenvolvimento de componentes com proteção e que possuam o mínimo de pontos críticos de falhas. Desta forma, é comum encontrarmos em servidores Web conexões redundantes, que se alternam em caso de falhas de conexão, sistemas que registram em dois ou mais discos o mesmo arquivo e fontes de energia que se alternam entre falhas elétricas.

A arquitetura da rede de computadores possui premissas de configuração para reduzir os pontos críticos de falhas, componentes específicos como Nobreaks e geradores à combustível, que visam garantir energia elétrica suficiente para manter operante os Servidores Web e componentes de rede necessários.

Dominar as técnicas de tolerância de falhas torna-se essencial aos desenvolvedores e projetistas para disponibilizar um serviço de qualidade e que possa se recuperar de forma eficiente. O custo-benefício é outro ponto importante que deve ser levado em consideração, pois o investimento em tecnologia de prevenção de falhas é muito bem visto e possui um mercado mundial em crescimento, onde alguns serviços de larga escala estão hospedados em mainframes de alto custo, mas garantem alta disponibilidade.

O conceito de Alta Disponibilidade não se restringe apenas à arquitetura da rede, mas sim a todo e qualquer tipo de falha de disponibilidade como parte física, servidores, discos e rede. Visando garantir Alta Disponibilidade a serviços críticos, surgem sistemas alternativos com hardware acessível, chamado de Cluster, que é um agregado de computadores interligados em rede que possui alta escalabilidade e custo mínimo.

Um Cluster é formado por um conjunto de computadores interligados através de uma rede, as máquinas membros deste cluster são denominadas nó ou node. É importante utilizar uma infraestrutura de rede que facilite a inclusão, alteração e exclusão de máquinas.

Na maioria das vezes, o cluster é formado de computadores convencionais e se apresenta de forma transparente ao usuário, como sendo um único computador de grande porte, é válido frisar que é possível a utilização de máquinas mais robustas para construção de Clusters.

Não é necessário que as máquinas sejam idênticas, mas sim o Sistema Operacional, para que os softwares que gerenciam as trocas de mensagens e sincronismo dos dados funcionem de forma correta.

De acordo com Zem (2005), existem hoje alguns tipos de cluster, mas alguns se destacam pela aplicação e custo benefício:

• Cluster de Alto Desempenho: denominado, também, de Alta Performance (High Performance Computing – HPC), sua característica é o grande volume de processamento de dados em computadores convencionais, que garante baixo custo na construção, e com processamento na ordem de gigaflops. Os servidores deste cluster trabalham com a tecnologia de paralelismo, dividindo o processamento com as outras máquinas, buscando a otimização e desempenho de um supercomputador.
• Cluster de Alta Disponibilidade: (High Availability – HA) são caracterizados por se manterem em pleno funcionamento por um longo período de tempo, utilizando redundância para manter um serviço ativo e se proteger de falhas, geralmente são computadores convencionais que disponibilizam o mesmo recurso em todas as máquinas da rede, configuradas com prioridades diferentes, onde existe um servidor ativo e os outros ociosos.
• Cluster de Balanceamento de Carga: (Horizontal Scaling – HS) são caracterizados por dividirem, de forma equilibrada, as tarefas entre os membros do cluster, onde cada nó atenda a uma requisição e não, necessariamente, que divida uma tarefa com outras máquinas.

É importante salientar, que é possível a combinação de mais de uma metodologia de construção de clusters, onde uma implementação de Alta Disponibilidade para garantir acesso aos serviços de vendas online, possa ser incrementada com a utilização de um cluster de Balanceamento de Carga para atender o aumento nos acessos ao serviço.

As características marcantes dos clusters são a facilidade de gerenciamento dos nós, onde podemos adicionar, dar manutenção e remover um nó do cluster sem que afete seu funcionamento, recuperação de falhas de forma otimizada. Podemos obter resultados tão satisfatórios no uso de um cluster quanto em servidores sofisticados com um custo muito menor. A implementação pode ser utilizada para aplicações sofisticadas e, também, para aplicações domésticas.

Os softwares livres Corosync Cluster Engine, Pacemaker e DRBD são instalados e configurados no Sistema Operacional Debian 7.1 para criar e gerenciar o cluster de forma adequada.

Explicado por Dake (2008), o Corosync Cluster Engine foi formalizado na conferência Ottawa Linux Symposium e foi uma redução do OpenAIS, sendo um sistema de comunicação de grupo para a implementação de alta disponibilidade dentro de servidores Linux.

Grupo de processos utilizam um modelo de comunicação fechado, com sincronia, tendo a capacidade de recuperar e receber notificações de alteração de informações de nós conectados.

A API (Application Programming Interface) interna do Corosync fornece os serviços através de uma implementação de um Totem – Single Ring Ordering and Membership Protocol – fornecendo o modelo virtual para troca de mensagens e membros do cluster, que confiabiliza a criação de réplicas de estado, reinício da aplicação em caso de falhas e sistema de quorum, que notifica sempre que a aplicação ou máquina venha a falhar.

Assim, o Corosync é considerado a evolução do Software Heartbeat, que possui recursos adicionais e mais suporte. Este software instalado e configurado cria o cluster preparado para ter várias funcionalidades, utiliza o tunelamento SSH para seu funcionamento e não mais o comando ping do Heartbeat.

O software Pacemaker, segundo Haas (2012), é um gerenciador de recursos de Cluster ou Cluster Resource Manager (CRM), sua função é oferecer uma interface para que o administrador possa gerenciar o Cluster. Possui muitas funcionalidades como capacidade de replicar as informações do Cluster entre os nós de maneira transparente e eficiente.

Depois de iniciado, o Pacemaker elege um nó coordenador designado entre os nós disponíveis e inicia as operações de cluster, desta forma, todas as tarefas de configuração precisam ser executadas em um nó somente e já são replicadas para todo o cluster automaticamente.

Através da linha de comando do Pacemaker, é possível criar tipos básicos e avançados de regras, nós de failover (é a capacidade de determinado serviço ser migrado automaticamente para um outro servidor), failback (é o processo de restauração de um serviço que se encontra em um estado de failover), monitoramento, migração e muitos outros recursos de Open Cluster Framework (OCF).

As configurações do Pacamaker são armazenadas em um arquivo XML, que é excelente para as máquinas e terrível para humanos, assim foram desenvolvidas algumas interfaces amigáveis para configuração adequada ocultando o XML.

O Software LCMC – Linux Cluster Management Console é uma interface gráfica construída em JAVA, que aborda uma forma nova de representar o estado e relações entre os serviços de um cluster. Utiliza SSH para instalar, configurar e gerenciar os clusters a partir de um terminal que contenha a interface gráfica instalada.

Distributed Replicated Block Device (DRBD) segundo Pla (2006), nada mais é que um módulo para espelhamento de armazenamento distribuídos, geralmente utilizado em clusters de alta disponibilidade – HA, isto é feito espelhando as partições do disco rígido via rede. O DRBD funciona como um sistema RAID baseado em rede.

O DRBD cria em todos os nós, um dispositivo virtual inacessível diretamente e toda a escrita é realizada no nodo primário, que irá transferir os dados para a partição e propagá-los para os restantes dos nós secundários.

Se o nó primário falhar, é realizada uma troca do nó secundário para primário e os dados são acessados normalmente e replicados aos outros nós, mas se o nó que falhou retornar, o DRBD, mediante as configurações, devolverá ou não o modo primário ao nó original, que ficará como secundário até o serviço ser encerrado nessa máquina.

Vale lembrar que DRBD não trabalha ao nível do sistema de arquivos, mas sim ao nível de blocos do disco rígido.

A implementação do cluster foi realizada inicialmente em máquinas virtuais, para testes, visando fácil locomoção, ambiente físico reduzido e clonagem dos nós é feita de forma rápida e confiável.

A máquina física hospedeira das virtuais utiliza processador Intel i3, com 4GB de memória RAM e HD de 1TB, cada máquina virtual possui 512MB de memória RAM, HD de 8GB e 02 placas de rede, salientando que na instalação do Debian 7.1 utilizaremos uma partição do HD para alocar o diretório /var, a qual será replicada no final das configurações.

As configurações das máquinas são mostradas abaixo:

• Máquina 01: Debian 7.1, hostname no01, IP eth0 10.0.2.15/24 (recebido via DHCP da máquina hospedeira que faz o NAT para acesso a internet) IP eth1192.168.0.1/24 (rede interna), domínio: dominio.com.br.
• Máquina 02: Debian 7.1, hostname no02, IP eth0 10.0.2.15/24 (recebido via DHCP da máquina hospedeira que faz o NAT para acesso a internet) IP eth1192.168.0.2/24 (rede interna), domínio: dominio.com.br.
• Máquina 03: Debian 7.1, hostname no03, IP eth0 10.0.2.15/24 (recebido via DHCP da máquina hospedeira que faz o NAT para acesso a internet) IP eth1192.168.0.3/24 (rede interna), domínio: dominio.com.br.

Os ajustes realizados nos nós foram feitos em apenas um nó e copiados via SSH para os outros nós, garantindo a não ocorrência erros de configurações diferentes. Atualização de repositórios de pacotes no arquivos “sources.list” e atualização com o comando:

# aptitude update && aptitude -y dist-upgrade

Ajuste no arquivo /etc/hosts, onde foram acrescentados os nós do cluster:

Assim, passamos para a instalação dos pacotes essenciais ao cluster:

# aptitude install -y corosync pacemaker ssh openssh-server

SSH COM TROCA DE CHAVES

Com o servidor SSH instalado, vamos gerar as chaves de SSH, em todos os nós, para efetuarmos a conexão via troca de chaves:

# ssh-keygen -t rsa

Agora temos que copiar as chaves do no01 para os nós no02 e no03, e assim por diante, até que todos os nós possuam todas as chaves dos outros nós. Na máquina no01, podemos executar o seguinte comando:

# ssh-copy-id 192.168.0.2
# ssh-copy-id 192.168.0.3

Nas demais máquinas, devemos executar o comando trocando os números dos endereços IPs dos respectivos nós. Desta forma, já temos comunicação SSH entre todas os nós do cluster.

CONFIGURAÇÃO DO COROSYNC

Ainda na máquina no01, iremos gerar a chave de autenticação para o Corosync com o seguinte comando:

# corosync -keygen

Assim que geradas as chaves na máquina no01 para o Corosync, iremos copiá-las para as máquinas no02 e no03 com o comando:

# scp /etc/corosync/authkey 192.168.0.2:/etc/corosync/authkey
# scp /etc/corosync/authkey 192.168.0.3:/etc/corosync/authkey

Iremos configurar o Corosync para que fique ativo na inicialização:

# sed -i ‘s/START=no/START=yes/g’ /etc/default/corosync

Fazer backup do arquivo de configuração:

# cp -a /etc/corosync/corosync.conf{,.bkp}

Agora faremos a edição do arquivo de configuração /etc/corosync/corosync.conf utilizando o editor nano, aproveitaremos os dados já inseridos no arquivo, alterando somente onde precisamos para nossa configuração:

# nano /etc/corosync/corosync.conf

Vamos copiar o arquivo alterado para o no02 e para o no03:

# scp /etc/corosync/corosync.conf 192.168.0.2:/etc/corosync/
# scp /etc/corosync/corosync.conf 192.168.0.3:/etc/corosync/

Vamos reiniciar o corosync em todos os nós:

# service corosync restart

CONFIGURAÇÃO DO PACEMAKER

Com a configuração do Corosync terminada e o serviço iniciado corretamente, já podemos utilizar o Pacemaker para disponibilizar os serviços do cluster, agora vamos testar se o cluster está funcionando.

Para o Pacemaker ser configurado, utilizaremos a linha de comando crm.

# crm_mon –one-shot -V

Desta forma, teremos o retorno dos nós ativos: Online [no01 no02 no03]

Agora no no01, vamos desabilitar o stonith para que ele não fique gerando erros, com o comando:

# crm configure property stonith-enabled=false

Podemos verificar se nosso cluster não tem nenhum problema da seguinte forma:

# crm_verify -L

Caso não encontre erros, ele não retorna nada.

Agora vamos desabilitar o quorum para não recebermos erros durante a configuração dos recursos, podemos executar em algum dos nós pois o cluster já está ativo e funcionando, pois as configurações serão replicadas para os outros nós:

# crm configure property no-quorum-policy=ignore

Para ser possível a movimentação de serviços entre os nós do cluster, sem a necessidade de alterarmos o endereço IP do serviço, o endereço IP associado ao serviço deverá ser configurado como um recurso do cluster para que ele possa ser movido livremente entre os nós do cluster junto com o serviço.

Iremos criar um recurso do tipo endereço IP 192.168.0.100 usando o RA IPaddr2, este IP será o endereço do Cluster, isto é, poderemos acessar o cluster e seus serviços através desse endereço, para configurar este recurso utilizaremos o comando:

# crm configure primitive IPdoApache ocf:heartbeat:IPaddr2 params ip=”192.168.0.100″ cidr_netmask=”24″ nic=eth1 op monitor interval=10s

Para verificar o serviço, utilizaremos:

# crm_mon -1

Teremos um retorno do tipo:

IPdoApache (ocf::heartbeat:IPaddr2): Started no01

Iremos definir em qual servidor o recurso deve ser alocado, com isso o Pacemaker já fez isso automaticamente elegendo um dos nós como padrão. Consultaremos o endereço IP configurado no servidor no01:

# ip addr show dev eth1

Note que no retorno, temos a configuração da interface eth1 com IP 192.168.0.1/24 e 192.168.0.100/24 como configuração secundária.

inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1
inet 192.168.0.100/24 brd 192.168.0.255 scope global secondary eth1

Iremos fazer os testes desligando o servidor no01, onde está o nosso recurso alocado, com o comando:

# shutdown -h now

Testando a configuração no no02:

# crm_mon -1

Teremos os seguintes retornos:

2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ no02 no03]
OFFLINE: [ no01 ]
IPdoApache (ocf::heartbeat:IPaddr2): Started no02

Neste momento, o Pacemaker já notou que a conexão com o no01 foi perdida por algum motivo e já passou o serviço para o no02. Lembrando que o no02 assumiu o serviço por decisão do Pacemaker e poderia ser o no03, mas isso podemos definir o nível de prioridade dos nós.

Mas antes, vamos religar a máquina do no01 e refazer o teste de comportamento:

# crm_mon -1
2 Nodes configured, 2 expected votes
1 Resources configured.
Online: [ no01 no02 no03]
IPdoApache (ocf::heartbeat:IPaddr2): Started no02

Note que o serviço continua alocado no no02 e o Pacemaker poderia voltar o serviço para o no01, no entanto, as prioridades de serviço estão no mesmo nível, então só voltará ao no01 quando o serviço for desalocado do no02 por desligamento ou parada do serviço.

CONFIGURAÇÃO DE RECURSO PARA MONITORAMENTO

Vamos começar o monitoramento com a instalação do Apache em todos os nós do cluster, com o seguinte comando:

# aptitude -y isntall apache2

Depois do Apache instalado, as requisições de protocolo HTTP via navegador de internet já funcionam com a resposta de “It works!” na tela do navegador. Antes de fazer os testes, vamos alterar o teor do arquivo “index.html” que fica no local /var/www de cada nó do cluster.

Para isso, usaremos o editor nano:

# nano /var/www/index.html

O conteúdo do arquivo deve ser configurado para a seguinte forma, apenas trocando “It works” para “No 01” e nos outros nós, o número específico de cada nó:

Para fins de testes, podemos ter em nossa rede, um terminal com qualquer Sistema Operacional que contenha interface gráfica para facilitar as operações. Assim podemos utilizar o navegador e acessar os nós digitando http://192.168.0.1 para o no01,http://192.168.0.2 para o no02, http://192.168.0.3 para o no03 e sucessivamente para mais nós, caso existam.

Com estas alterações, teremos visivelmente as respostas de requisição de cada servidor Apache, e podemos identificar qual é o servidor ativo no momento. Agora vamos configurar um recurso do Cluster para monitorar o Apache2:

# crm configure primitive RecursoApache lsb:apache2

Consultando, outra vez os recursos do Cluster:

# crm_mon -1
Online: [ nodo1 nodo2 no03]
IPdoApache (ocf::heartbeat:IPaddr2): Started no02
RecursoApache (lsb:apache2): Started no01

Percebam que os recursos estão no servidor no02 e no01, isto é, separados, o recurso de monitoramento do Apache2 está iniciado em no01 e monitoramento do IP do cluster em no02, assim para facilitar a movimentação e o gerenciamento de recursos associados a um serviço, podemos agrupar todos esses recursos em um único grupo, onde podemos definir o local de prioridade alta, média e baixa, sendo que todos os recursos serão movidos para a localização que desejamos e não mais decidido pelo Pacemaker.

Vamos utilizar o comando:

# crm configure group GrupodoServidor RecursoApache IPdoApache

Novamente, vamos consultar os recursos:

# crm_mon -1

Teremos o retorno da seguinte forma:

Resource Group: GrupodoServidor
RecursoApache (lsb:apache2): Started no01
IPdoApache (ocf::heartbeat:IPaddr2): Started no01

Podemos perceber que os recursos estão agora alocados somente no servidor no01 e o grupo se encarrega de mantê-los unidos, assim podemos definir a prioridade dos nós do cluster. Neste modelo de configuração não havia necessidade de definir prioridades de nós no cluster, pois todas as máquinas são iguais em memória RAM, CPU e espaço em disco, mas em máquinas reais nem sempre conseguiremos montar um Cluster com máquinas idênticas, pois alguma que seja adicionada posteriormente, pode ter melhorias e evoluções de hardware.

Um exemplo seria um cluster formado com três nós de computadores convencionais, onde cada um deles é diferente do outro, sendo o nó 01 um computador de última geração com memória RAM e CPU muito rápidos, nó 02 um computador intermediário com a metade dos recursos de hardware do nó 01 e o nó 03 um computador bem simples com a metade dos recursos de hardware do nó 02.

Assim ficaria interessante se manipulássemos os recursos do cluster para que se aloquem no nó que possua o melhor hardware, fazendo que as requisições sejam resolvidas mais rápidas, como nó 01 – 100, nó 02 – 80 e nó 03 – 60, sendo que a prioridade 100 é mais alta e 0 a mais baixa.

Caso o nó 01 venha a falhar, caracterizando failover, quem assumiria seria o nó 02 (intermediário em hardware), somente se o nó 02 falhar é que o nó 03 seria ativado, ainda que o hardware seja bem obsoleto, as requisições seriam resolvidas e teríamos a caracterização do Cluster HA (alta disponibilidade).

Nas falhas dos nós 01 e 02, que puderam ser recuperadas e o servidor voltou a ativa o Pacemaker percebe que o nó 01 retornou ao cluster e analisa a prioridade do nó 01, sendo a prioridade do nó 01 -100 e a do nó 03 – 60 a alocação de recurso é transferida de volta para o nó 01 caracterizando failback.

Assim, para configurarmos as prioridades, utilizaremos o comando colocando após o grupo de recursos a prioridade e o nó:

# crm configure location HTTP_Server GrupodoServidor 100: no02

Podemos consultar a configuração do Pacemaker utilizando:

# crm configure show

E veremos que: location HTTP_Server GrupodoServidor 100: no02

TESTE DE COROSYNC E PACEMAKER

Com todas as configurações realizadas, o Cluster HA está disponível e configurado, os recursos do cluster já estão disponíveis e seu endereço é http://192.168.0.100 e podemos acessá-lo no terminal apenas digitando no navegador de internet o endereço acima.

Podemos perceber que na requisição de protocolo HTTP, aparece no navegador a configuração que fizemos no arquivo/var/www/index.html, que é o arquivo padrão do Apache2, neste caso, é mostrado no navegador “No 02”, pois os serviços estão alocados no servidor no02.

Agora podemos testar desligando o no02 ou interrompendo seu recurso:

• Para desligar, usamos: shutdown -s now
• Para parar o recurso, usamos: crm node standby nodo2

Assim que um dos dois comandos sejam realizados, podemos atualizar a página no navegador do terminal e veremos que o serviço continua ativo, embora o servidor no02 esteja com falha, mas podemos notar que a página mudou e agora mostra “No 01”, ao religar o servidor no02 o serviço retorna ao nó com maior prioridade, neste caso no02, como já mencionado.

Os recursos do Cluster podem ser manipulados, onde é possível parar o recurso:

# crm resource stop NomedoRecurso

Trocando stop por start, faz com que o recurso seja iniciado. Para remover um recurso, utilizamos:

# crm configure delete NomedoRecurso

Podemos notar que o Cluster está ativo e em funcionamento, no entanto, nas requisições de acesso estão mudando apenas o recurso alocado em um nó para outro nó e os arquivos acessados são diferentes como demonstrado no teste acima. A partir daí, utilizaremos oDRBD, que é um replicador de blocos, que faz a replicação dos dados para outro nó.

Como o HD tem uma partição exclusiva para replicação, o qual servirá para alocar o diretório /var, podemos fazer a configuração de replicação e depois alterar de lugar o diretório /var, ou alterar o arquivo do Apache2 para buscar os arquivos html na nossa partição replicada, primeiramente, instalar o DRBD em cada um dos nós, farei no nó no01:

# aptitude install drbd8-utils

Depois de instalado, vamos carregar os módulos:

# modprobe cn
# modprobe drbd

Configurar o DRBD e inserir o seguinte parâmetro:

# nano /etc/drbd.d/global_common.conf

Altere a seguinte linha:

Alterar o arquivo /etc/drbd.d/ro.res:

# nano /etc/drbd.d/r0.res

A alteração pretendida neste arquivo é configurar as partições do HD onde estão o diretório /var, que no meu caso, é /dev/hdb1:

Zerando as partições dos nós do cluster:

# dd if=/dev/zero of=/dev/hdb1 bs=1M count=128

Inicializando os recursos executando em todos os nós:

# drbdadm create-md r0
# modprobe drbd
# drbdadm up r0

Sincronizando pela primeira vez, fazendo apenas no nó no01:

# drbdadm — –overwrite-data-of-peer primary r0

Aguardar a finalização do sincronismo, o tempo depende do tamanho do recurso e velocidade da conexão entre os nó. Iniciando o serviço do DRBD:

# service drbd restart

Formatando o dispositivos criados nos passos anteriores, fazendo apenas no primeiro nó:

# mkfs.ext4 /dev/drbd0

Nome do diretório opcional, caso queira configurar o Apache2 para buscar os arquivos aqui:

# mkdir /dados

Montando o dispositivo:

# mount -t ext4 /dev/drbd0 /dados

TESTES COM DRBD

Vamos criar um arquivo no diretório onde foi montado o drbd:

# nano /dados/teste

Vamos desmontar o dispositivo, lembre-se que é necessário sair do dispositivo:

# umount /dados

Mudando o nó primário para secundário:

# drbdadm secondary all

Mudando outro nó do Cluster em primário, neste caso, nó no02 ou no03:

# drbdadm primary all

Montando o dispositivo no nó que se tornou primário:

# mount -t ext4 /dev/drbd0 /dados

Assim o arquivo foi replicado com sucesso.

O emprego de um Cluster de Alta Disponibilidade (HA) para Servidores Web é uma das soluções que tem a melhor relação custo-benefício, pois são utilizados computadores convencionais, que juntos conseguem atingir os níveis exigidos para classificação de Alta Disponibilidade, chegando a 99,99% de disponibilidade por ano.

A vantagem da utilização é a manutenção programada, que mantém o recurso disponível mesmo com o desligamento de algumas máquinas e a inclusão de novos nós no Cluster é feita de forma simples.

Assim, esta estrutura de servidores em rede (Cluster) pode ser empregada como Servidores, como exemplo, do Instituto Federal de Educação, Ciência e Tecnologia do Sul de Minas Gerais – Campus Muzambinho – MG, em todos os serviços do domínio muz.ifsuldeminas.edu.br (Servidores Apache, MySQL, Samba, entre outros).

Mas devemos ter o cuidado para implantarmos em uma DMZ – zona desmilitarizada – para que a vulnerabilidade de invasões não se torne um ponto de falhas.