http://www.vivaolinux.com.br/artigo/Alta-disponibilidade-com-Debian-Lenny-+-Heartbeat+-DRBD8-+-OCFS2-+-MONIT-+-LVS?

pagina=1

12/03/2014 Um pouco de histria

Cada vez mais necessrio garantir a disponibilidade de um servio, mas sendo que muitos componentes dos sistemas de informao atuais contm partes mecnicas, a confiabilidade destes relativamente insuficiente se o servio for crtico. Para garantir a ausncia de interrupes de servio necessrio, muitas vezes, dispor de hardware redundante que entre em funcionamento automaticamente quando da falha de um dos componentes em utilizao. Quanto mais redundncia existir, menores sero os SPOF (Single Point Of Failure), e menor ser a probabilidade de interrupes no servio. At poucos anos atrs tais sistemas eram muito dispendiosos e tem-se vindo a intensificar uma procura em solues alternativas. Surgem ento os sistemas construdos com hardware acessvel (clusters), altamente escalveis e de custo mnimo. A figura 1 ilustra a configurao tpica de um sistema de alta disponibilidade dual-node.

Como se pode observar, no existe um nico ponto nesta arquitetura que, ao falhar, implique a indisponibilidade de outro ponto qualquer (SPOF). O fato de ambos os servidores se encontrarem em funcionamento e ligados rede no implica, porm, que se encontrem a desempenhar as mesmas tarefas. Esse uma deciso por parte do administrador e que tem o nome de balanceamento de carga. A tabela 1 ilustra um dos termos de comparao geralmente utilizado na avaliao de solues HA: nveis de disponibilidade segundo tempos de indisponibilidade (downtime). Excludos desta tabela, os tempos de downtime estimados (geralmente para manuteno ou reconfigurao dos sistemas) so alheios s solues e muito variveis. Tabela 1 - Nveis de alta disponibilidade

Disponibilidade (%) 95% 96% 97% 98% 99% 99,9% 99,99% 99,999%

Downtime/ano 18 dias 6:00:00 14 dias 14:24:00 10 dias 22:48:00 7 dias 7:12:00 3 dias 15:36:00 0 dias 8:45:35.99 0 dias 0:52:33.60 0 dias 0:05:15.36

Downtime/ms 1 dias 12:00:00 1 dias 4:48:00 0 dias 21:36:00 0 dias 14:24:00 0 dias 7:12:00 0 dias 0:43:11.99 0 dias 0:04:19.20 0 dias 0:00:25.92

Geralmente, quanto maior a disponibilidade, maior a redundncia e custo das solues: tudo depende do tipo de servio que se pretende disponibilizar. Por exemplo, um operador de telecomunicaes querer certamente o mais elevado a fim de poder garantir um elevado nvel de disponibilidade, sob pena de perder os seus clientes caso o sistema sofra falhas constantemente. No entanto, uma empresa com horrio de trabalho normal poder considerar que 90% de disponibilidade sero suficientes. de salientar que o nvel de disponibilidade mensal no o

mesmo que o anual. Efetivamente, para se obter um nvel de disponibilidade mensal de 97%, necessrio que o nvel anual seja aproximadamente de 99,75%. A tolerncia a falhas consiste, basicamente, em ter hardware redundante que entra em funcionamento automaticamente aps a deteco de falha do hardware principal. Independentemente da soluo adotada, existem sempre dois parmetros que possibilitam mensurar o grau de tolerncia a falhas que so o MTBF - Mean Time Between Failures - (tempo mdio entre falhas) e o MTTR - Mean Time To Repair - tempo mdio de recuperao, que o espao de tempo (mdio) que decorre entre a ocorrncia da falha e a total recuperao do sistema ao seu estado operacional. A disponibilidade de um sistema pode ser calculada pela frmula: Disponibilidade = MTBF / (MTBF + MTTR) Fonte: http://pt.wikipedia.org/wiki/Disponibilidade

Clusters de alta disponibilidade

Em vez de montar um nico servidor com componentes redundantes, existe tambm a opo de usar um cluster de alta disponibilidade (chamado de "high-availability cluster" ou "failover cluster"), onde so usados dois servidores completos, onde a nica funo do segundo servidor assumir a posio do primeiro em caso de falhas (modo chamado de ativo/passivo), diferente de um cluster com balanceamento de carga, onde os servidores dividem as requisies (ativo/ativo). Existem diversas solues para clusters de alta disponibilidade. Entre as solues abertas, uma das mais usadas o projeto Linux-HA (High-Availability Linux, disponvel no http://www.linuxha.org), que desenvolve o Heartbeat, um daemon responsvel por monitorar o status dos servidores do cluster e permitir que o segundo servidor assuma as funes do primeiro em caso de pane. Cada um dos servidores possui pelo menos duas placas de rede, o que permite que eles sejam simultaneamente ligados rede e ligados entre si atravs de um cabo crossover ou de um switch dedicado. A conexo interna usada pelo Heartbeat para as funes de monitoramento e sincronismo dos processos, de forma que o segundo servidor possa assumir imediatamente a funo do primeiro quando necessrio, assumindo o endereo IP anteriormente usado por ele. comum tambm o uso de uma terceira interface de rede em cada servidor (ligada a um switch separado), destinada a oferecer uma conexo de backup com a rede. Isso permite eliminar mais um possvel ponto de falha, afinal, de nada adianta ter servidores redundantes se o switch que os liga rede parar de funcionar. :) Em geral, o Heartbeat usado em conjunto com o Drbd, que assume a funo de manter os HDs dos dois servidores sincronizados, como uma espcie de RAID 1 via rede. Ao usar o Drbd, o HD do segundo servidor assume o papel de unidade secundria e atualizado em relao ao do primeiro em tempo real. Quando o primeiro servidor pra, a unidade de armazenamento do segundo servidor passa a ser usada como unidade primria. Quando o servidor principal retorna, o HD sincronizado em relao ao secundrio e s ento ele reassume suas funes. Outra opo utilizar uma SAN (veja a seguir) para que os dois servidores compartilhem a mesma unidade de armazenamento. Nesse caso, no necessrio manter o sincronismo, j que os dados so armazenados em uma unidade comum aos dois servidores. Como pode ver, adicionar componentes redundantes, sejam fontes, HDs ou servidores adicionais aumentam consideravelmente os custos. A principal questo avaliar se o prejuzo de ter o servidor fora do ar por algumas horas ou dias durante as manutenes, acidentes e imprevistos em geral maior ou menor do que o investimento necessrio. Um pequeno servidor de rede local, que atende a meia dzia de usurios em um pequeno escritrio dificilmente precisaria de redundncia, mas um servidor de misso-crtica (como no caso de um banco) com certeza precisa. Cada nvel de redundncia adiciona um certo valor ao custo dos servidores, mas reduz em certa proporo o tempo de downtime. A disponibilidade do servidor genericamente medida em "noves". Um nove indica uma disponibilidade de 90%, ou seja, uma situao em que o servidor fica fora do ar at 10% do tempo (imagine o caso de uma mquina instvel, que precisa ser freqentemente reiniciada, por exemplo), o que no admissvel na maioria das situaes. Com dois noves temos um servidor que fica disponvel 99%, o que seria uma boa marca para um

servidor "comum", sem recursos de redundncia. Por outro lado, uma disponibilidade de 99% significa que o servidor pode ficar fora do ar por at 7 horas e 18 minutos por ms (incluindo todas as manutenes, quedas de energia, operaes de backup que tornem necessrio parar os servios e assim por diante), o que tolervel no caso de uma rede local, ou no caso de um servidor que hospeda um site fora da rea de comrcio eletrnico, mas ainda no adequado para operaes de misso crtica. Para adicionar mais um nove, atingindo 99.9% de disponibilidade (o famoso "three nines"), no possvel mais contar apenas com a sorte. necessrio comear a pensar nos possveis pontos de falha e comear a adicionar recursos de redundncia. Entram em cena as fontes redundantes, o uso de uma controladora RAID com suporte a hot-swap, uso de um nobreak com boa autonomia para todo o equipamento de rede, de forma que o servidor continue disponvel mesmo durante as quedas de luz, e assim por diante. Afinal, 99.9% de disponibilidade significa que o servidor no fica fora do ar por mais de 43 minutos por ms. No caso de servidores de misso crtica, qualquer interrupo no servio pode representar um grande prejuzo, como no caso de instituies financeiras e grandes sites de comrcio eletrnico. Passa ento a fazer sentido investir no uso de um cluster de alta disponibilidade e em links redundantes, de forma a tentar atingir 99.99% de disponibilidade. Esta marca difcil de atingir, pois significa que o servidor no deve ficar mais do que 4 minutos e meio (em mdia) fora do ar por ms, incluindo a tudo o que possa dar errado. Como sempre, no existe uma frmula mgica para calcular o ponto ideal ( justamente por isso que existem consultores e analistas), mas sempre prudente ter pelo menos um nvel mnimo de redundncia, nem que seja apenas um backup atualizado, que permita restaurar o servidor (usando outra mquina) caso alguma tragdia acontea. Referncia: http://www.gdhpress.com.br/servidores/leia/index.php?p=cap14-3 Este artigo cobre como implementar a alta disponibilidade, ela pode ser aplicada a vrios tipos de servios. Heartbeat funciona como gestor do cluster e dos seus recursos. Como o nome indica, a sinalizao da presena (ou ausncia) de contato com os nodos do cluster faz-se mediante o envio de pequenos pacotes (heartbeats, batimentos cardacos) dirigidos a todos os nodos do cluster, cuja confirmao de recepo por parte de cada nodo indica o estado desse nodo. Fonte: http://pt.wikipedia.org/wiki/Linux-HA DBRD a acrnimo para o nome ingls Distributed Replicated Block Device. O DRBD consiste num mdulo para o ncleo Linux que, juntamente com alguns scripts, oferece um dispositivo de bloco projetado para disponibilizar dispositivos de armazenamento distribudos, geralmente utilizado em clusters de alta disponibilidade. Isto feito espelhando conjuntos de blocos via rede (dedicada). O DRBD funciona, portanto, como um sistema RAID baseado em rede. Fonte: http://pt.wikipedia.org/wiki/Drbd OCFS2 um sistema de arquivos de cluster para Linux capaz de fornecer tanto de alto desempenho quanto alta disponibilidade. Uma vez que fornece a semntica do sistema de arquivos local, ele pode ser usado com qualquer aplicao. Como cluster de aplicaes sensveis pode fazer uso de I/O paralelo para um melhor desempenho e fornecer um failover de configurao para aumentar a sua disponibilidade. Alm de ser usado com o Oracle Real Application Cluster de banco de dados do produto, OCFS2 est atualmente em uso para fornecer servidores de web escalveis e servidores de arquivo, bem como fail-over-mail e servidores para hospedagem de imagens da mquina virtual. E pode ser utilizado para as mais diversas finalidades dentro de um sistema, no somente para os Bancos de dados, mas sim para qualquer partio na qual se deseje o acesso simultneo de vrios clientes. Algumas das caractersticas notveis do sistema de arquivos so:

Tamanho varivel de bloco

Alocao flexvel (extenses, escasso, as extenses no-escrita com a capacidade de furos)

Journaling (ordenado e dados de write-back dirio modos) Endian e Arquitetura Neutro (x86, x86_64, ia64 e ppc64) In-built Clusterstack com um Distributed Lock Manager Suporte para Buffered, Direct, Asynchronous, Splice e Memory Mapped I / Os Cluster Ferramentas de conhecimento (mkfs, fsck, tunefs etc)

Fonte: http://oss.oracle.com/projects/ocfs2 Monit um utilitrio de cdigo aberto para gerenciamento e monitoramento, processos, arquivos, diretrios e arquivos em um sistema UNIX. Monit efetua manuteno e reparo automtico e pode executar aes significativas em situaes de erro. O que pode fazer o Monit? Monit pode iniciar um processo se no funcionar, reiniciar um processo se ele no responder e interromper um processo, se ele usa recursos demais. Voc pode usar Monit para monitorar arquivos, diretrios e arquivos para mudanas, como alteraes carimbo do tempo, alteraes ou mudanas de verificao de tamanho. Voc tambm pode controlar mquinas remotas; Monit pode executar ping um host remoto e pode verificar conexes TCP / IP e porta do servidor. Monit controlado atravs de um arquivo de controle baseados em um formato livre, sintaxe tokenorientado. Os logs do Monit podem ser para o syslog ou ao seu prprio arquivo de log e notific-lo sobre as condies de erro e status de cobrana por via de alerta customizvel. Fonte: http://mmonit.com/monit/ LVS Linux Virtual Server (LVS) uma soluo de balanceamento de carga avanada para sistemas Linux. um projeto Open Source comeado por Wensong Zhang em maio de 1998. A misso do projeto construir um servidor de alto desempenho e altamente disponvel para Linux usando a tecnologia de clustering, que fornece altos nveis de escalabilidade, confiabilidade e usabilidade. O trabalho principal do projeto de LVS deve agora desenvolver o software de balanceamento de carga avanado de IP (IPVS), o software de balanceamento de carga a nvel aplicativo (KTCPVS) e componentes de gerenciamento de cluster. IPVS: um software balanceador de carga avanado do IP executado dentro do Linux. O cdigo de IPVS era j includo no ncleo padro 2.4 e 2.6 de Linux. KTCPVS: executa a carga do nvel de aplicao que balana dentro do Linux, atualmente sob desenvolvimento. Os usurios podem usar as solues de LVS para construir servios de rede altamente escalveis e altamente disponveis, tais como o servio de mdia, servio de email. Os meios prestam servios de manuteno e servios de VoIP, e integram servios de rede escalveis em aplicaes de confiana em grande escala do e-comrcio ou do e-governo. As solues de LVS tm sido desdobradas j em muitas aplicaes reais durante todo o mundo. Fonte: http://pt.wikipedia.org/wiki/LVS Para mais informaes a respeito dessas ferramentas podem ser consultados os links abaixo.

Heartbeat DRBD

OCFS2 MONIT LVS

Essas ferramentas so timas para garantir a alta disponibilidade dos nossos servidores como pode ser visto. A implementao um pouco trabalhosa na primeira vez, mas com o passar do tempo isso fica bem fcil que voc pode at criar um script para fazer tudo isso. S no vo achando que este artigo vai deixar voc um expert em alta disponibilidade, eu s vou dar o caminho das pedras e vocs tem que ir seguindo em diante. Dependendo da distribuio GNU/Linux isso pode se tornar mais fcil ou mais difcil em questo de trabalho, fora isso aplicado a qualquer distro. No momento estou fazendo esta implementao em FreeBSD, assim que terminar vou publicar as diferenas na implementao. Ento chega de histria, s os oriento a pesquisarem mais sobre o assunto e fazerem muitos testes antes de colocarem em produo por que s com o tempo para ir se familiarizando com os possveis erros. Vamos comear!

Nosso ambiente de implementao

Nosso cenrio. Vamos implementar a alta disponibilidade utilizando 2 mquinas. Primeira mquina:

SO: Debian Lenny GNU/linux IP: 192.168.0.1 Hostname: debian Domnio: dominio.com.br Interfaces de rede: eth0 eth1 Partio livre: /dev/sda11 de 2 GB

Segunda mquina:

SO: Debian Lenny GNU/linux IP: 192.168.0.2 Hostname: debian2 Domnio: dominio.com.br Interfaces de rede: eth0 eth1 Partio livre: /dev/sda11 de 2 GB OBS:Esta partio livre ser utilizada para os testes com o DRBD e OCFS2.

Precisaremos de 2 interfaces no mnimo, se possvel uma delas pode estar ligada com um cabo crossover entre as duas mquinas do nosso cluster para termos uma melhor taxa de transferncia de dados nas nossas replicaes e uma interface ligada em um switch por exemplo para podermos sair para para a internet. Seno pode usar as duas interfaces ligadas a um hub ou a um switch. As configuraes nas duas mquinas no arquivo /etc/hosts tem que ser a seguinte, pois em caso de falha de resoluo de nomes temos este arquivo para nos referenciarmos s mquinas. # vim /etc/hosts 127.0.0.1 localhost 192.168.0.1 debian.dominio.com.br debian 192.168.0.2 debian2.dominio.com.br debian2 Vamos precisar que isso seja configurado corretamente nas duas mquinas, pois seno teremos problemas com a nossa alta disponibilidade. Para os servios do DRBD e do OCFS2 temos que informar os nomes das mquinas, que no nosso exemplo esto como debian e debian2. Para confirmar o nome da mquina utilize o seguinte comando. # uname -n O resultado tem que ser debian na mquina 192.168.0.1 e debian2 na mquina 192.168.0.2.

Caso no seja, edite o arquivo /etc/hostname e coloque o o nome correto debian na mquina 192.168.0.1 e debian2 na mquina 192.168.0.2. # vim /etc/hostname debian Ou: # vim /etc/hostname debian2 Pronto, os nossos pr-requisitos esto ok.

Preparao do ambiente
Antes de comearmos a efetuar a nossa implementao vamos seguir alguns passos. Primeiro ajustar os repositrios, pois no adianta tentar achar todos os pacotes que vamos precisar no DVD de instalao que no vai ter. Ento faa um backup do arquivo de repositrio caso precise depois. Efetuando backup do arquivo do apt: # mv /etc/apt/sources.list /etc/apt/sources.list.orig Editando o arquivo do apt com os seguintes repositrios: # vi /etc/apt/sources.list # Repositrio oficial Brasil deb ftp://ftp.br.debian.org/debian lenny main contrib non-free deb-src ftp://ftp.br.debian.org/debian lenny main contrib non-free #Se quiser utilizar os repositrios USA descomente a linha deb ftp://ftp.us.debian.org/debian lenny main contrib non-free deb-src ftp://ftp.us.debian.org/debian lenny main contrib non-free # Repositrio de atualizaes frequentes deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free deb-src http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free # Repositrio de atualizaes de segurana deb http://security.debian.org/ lenny/updates main contrib non-free deb-src http://security.debian.org/ lenny/updates main contrib non-free # Repositrio de atualizaes propostas deb ftp://ftp.br.debian.org/debian lenny-proposed-updates main contrib non-free deb-src ftp://ftp.br.debian.org/debian lenny-proposed-updates main contrib non-free Atualizando as chaves de repositrio (KEYRINGS): # aptitude -y install debian-backports-keyring # gpg --keyserver wwwkeys.pgp.net --recv-keys 1F41B907 # apt-key add ~root/.gnupg/pubring.gpg Vamos instalar os pacotes de pr-requisitos para no termos problemas com falta de algum aplicativo. Aqui eu estou instalando o vim, mas se no quiser utilizar este editor use o seu editor preferido. # # # # # # aptitude aptitude aptitude aptitude aptitude aptitude -y -y -y -y -y -y install install install install install install vim vim-scripts ctags vim-doc zip unzip rar p7zip bzip2 less links telnet pciutils locate openssh-server sysv-rc-conf htop nmap tcpdump rsync build-essential libncurses5-dev

Vamos ajustar a hora: # apt-get -y remove --purge tz-brasil # aptitude -y install ntpdate tz-brasil

# ntpdate -u ntp.usp.br # hwclock --systohc Vamos atualizar todo o sistema agora, pois precisamos ter uma base atualizada para termos uma boa compatibilidade de aplicativos, caso voc no queira efetuar este processo, fique ciente que algo pode dar errado, "LEI DE MURPH" muito bem empregada em alta disponibilidade. # aptitude -y dist-upgrade

Instalao e configurao do Heartbeat

Vamos instalar os pacotes do Heartbeat verso 2. O pacote do heartbeat-2-gui pode ser instalado em alguma outra mquina que no seja o servidor, pois este pacote do gerenciador GUI do Heartbeat e muito bom utilizar este aplicativo para configurar o cluster e os servios caso haja necessidade, pois os arquivos com as configuraes dos servios no Heartbeat2 so em XML "cib. xml" e so bem fceis de darem problema caso sejam modificados manualmente. Obs.: Os arquivos do Heartbeat tm que estar em sincronismo para no dar nem um problema, caso contrrio os servios no vo funcionar corretamente, como a configurao de um cluster MySQL se as bases e os arquivos .bin no estiverem em sincronia vai dar problemas. Instalao dos pacotes do Heartbeat. # aptitude install heartbeat-2 heartbeat-2-dev heartbeat-2-gui -y Depois de instalado vamos configurar os arquivos. Toda a configurao do Heartbeat fica em /etc/ha.d/. Vamos comear criando e configurando o arquivo authkeys, que utilizando para a autenticao. Este arquivo deve conter a permisso 600. Nos arquivos eu coloco algumas "#" para inserir os comentrios, ento no confundam. # vim /etc/ha.d/authkeys # /etc/ha.d/authkeys #Definir qual o mtodo de autenticao. auth 3 #Mtodos de autenticao disponveis 1 crc 2 sha1 senha 3 md5 senha No arquivo acima deve ser informada a senha nos mtodos 2 e 3, por que seno o Heartbeat gera um erro e no inicia. Vamos definir as permisses. # chmod 600 /etc/ha.d/authkeys Vamos agora configurar o arquivo responsvel pela definio das diretivas globais de funcionamento do Heartbeat. # vim /etc/ha.d/ha.cf #/etc/ha.d/ha.cf #Intervalo em segundos entre os pings keepalive 1 #Intervalo em segundos para declarar uma mquina inativa deadtime 3 #Fazer com que a mquina principal receba seus servios quando retornar a ativa

auto_failback on #Porta de comunicao entre as mquinas. Padro 694 (/etc/services) udpport 694 #Interface de comunicao do subsistema. Deve ser a mesma para todas as mquinas udp eth0 #Utilizar o daemon de Log (Heartbeat Verso 2) use_logd on #Nome das mquinas que participam do cluster #Pode ser visualizado com o comando "uname -n" #Podem ser colocadas de 2 a N mquinas node debian debian2 #Habilita o Gerenciamento de Recursos do Cluster Heartbeat Verso 2 crm on Este arquivo pode ter a permisso como 640. Vamos setar as permisses: # chmod 640 /etc/ha.d/ha.cf Vamos agora criar o arquivo de gerenciamento de logs do Heartbeat. # vim /etc/logd.cf #/etc/logd.cf #Arquivo de depurao do subsistema debugfile /var/log/ha-debug #Arquivo de armazenamento de logs logfile /var/log/ha-log Este arquivo tem que ter a permisso 640 e o grupo como haclient, vamos setar as permisses agora. # chmod 640 /etc/logd.cf # chgrp haclient /etc/logd.cf Pronto, temos o Heartbeat configurado em uma mquina, agora podemos s copiar os arquivos via rsync para a outra mquina que temos as duas configuradas. # rsync -Hxpagouvt /etc/ha.d/authkeys 192.168.0.1:/etc/ha.d/ # rsync -Hxpagouvt /etc/ha.d/ha.cf 192.168.0.1:/etc/ha.d/ # rsync -Hxpagouvt /etc/logd.cf 192.168.0.1:/etc/logd.cf Ou se voc estiver na mquina 192.168.0.1. # rsync -Hxpagouvt /etc/ha.d/authkeys 192.168.0.2:/etc/ha.d/ # rsync -Hxpagouvt /etc/ha.d/ha.cf 192.168.0.2:/etc/ha.d/ # rsync -Hxpagouvt /etc/logd.cf 192.168.0.2:/etc/logd.cf Com esse comando ns mantemos todas as permisses dos arquivos. Pronto, agora s confirme nas duas mquinas se os arquivos esto l e vamos iniciar o servio. Vamos garantir que ele esteja parado e vamos inici-lo.

# /etc/init.d/heartbeat stop # /etc/init.d/heartbeat start Os logs podem ser vistos em /var/logs/syslog e nos arquivo que configuramos, /var/log/ha-log e /var/log/ha-debug. Se tudo correu bem vai aparecer a seguinte mensagem depois de iniciar o servio. Starting High-Availability services: Done.

Gerenciando o Heartbeat com Haclient

Agora que j temos os dois servidores configurados e com os servios funcionando, vamos acrescentar os servios que sero gerenciados. Vamos instalar o Apache nos dois servidores j para efetuarmos alguns testes, pois vamos utilizar ele mais para frente. # aptitude install apache2 -y Como na instalao do Heartbeat ele no pediu senha para o hacluster, temos que inserir uma para podemos conectar no Heartbeat. # passwd hacluster Agora que definimos a senha vamos continuar. Vamos definir as configuraes de rede para o nosso cluster, ento vamos iniciar o nosso haclient. Se voc instalou o heartbeat-2-gui em uma mquina separada, no sendo um dos nossos nodos do cluster, s abrir um terminal como root e chamar o nosso aplicativo da seguinte forma. # /usr/lib/heartbeat-gui/haclient.py & Ou se voc instalou no servidor pode exportar do o haclient para o cliente. Eu aconselho sempre instalar o haclient em uma mquina separada para no ficar enchendo o servidor de bibliotecas e pacotes de ambiente grfico. Voc tambm pode usar o putty em GNU/Linux habilitando em Connection/SSH/X11 a opo X11 forward e conectar no servidor e chamar o comando: # /usr/lib/heartbeat-gui/haclient.py & Que o putty importa o haclient para a mquina local para podermos gerenciar o nosso heartbeat. Depois de chamarmos o nosso aplicativo temos que conectar no servidor. No console clique em Connection/Login. Vai aparecer a tela de login. Devemos informar para qual servidor queremos conectar, pode ser em qualquer um dos nodos do cluster, pois vai ser replicada a configurao automaticamente para o outro nodo, o usurio vai ser o hacluster, que j est na tela de login por padro e a senha que foi definida no comando "passwd hacluster", depois disso s clicar em ok. Pronto, essa a maravilhosa tela do haclient. Pode notar que do lado esquerdo da tela nos temos os nossos nodos do cluster em crculos verde, que significa que esto trabalhando normalmente. Logo aps os crculos verdes temos a palavra running, ento o nosso servidor est trabalhando corretamente. Agora vamos configurao do endereo IP que o nosso cluster vai usar. Em primeiro lugar vamos a algumas consideraes, como estamos trabalhando com cluster, os nossos dois servidores tero que ser vistos como somente um, e vamos trabalhar sempre com grupos que fica uma melhor organizao.

Ento clique com o boto direito do mouse na opo Resources do lado esquerdo da tela abaixo do nome dos nossos nodos. Selecione a opo Add New Item, na prxima tela escolha a opo group. Na prxima tela digite um ID para o seu grupo exemplo Web_Servers e clique em ok. Nessa nova tela que apareceu temos que criar um recurso nativo, ou seja, um servio que vai ser monitorado. Na primeira opo Resource ID de o nome de IP_WebServers. Na parte logo abaixo de Resource ID temos a seleo de recursos. Vamos escolher o recurso ipaddr2. E note que depois que escolhemos o recurso temos a opo parameters: Temos que deletar o parmetro que vem por default nessa opo note que nesta parte da tela do lado direito tem dois botes um add parameter e outro delete parameter, clique no parmetro que veio por default e clique em delete parameter. E agora vamos adicionar os novos parmetros. Clique em add parameter. Vai abrir uma nova tela, selecione em name a opo IP e em value digite o IP para o seu cluster exemplo 192.168.0.3. Mas para que isso? Vou explicar. Quando voc for fazer uma solicitao de algum servio para o cluster, no ser necessrio escolher uma das mquinas do cluster, quem vai se encarregar disso vai ser o Heartbeat e ele vai se referenciar por esse IP que estamos configurando. Exemplo: Estou com a mquina 192.168.0.1 trabalhando e o Heartbeat deu o IP 192.168.0.3 na placa virtual para ela, mas ela deu problema e tem que ser desligada. Quando esta mquina for desligada, o Heartbeat vai detectar isso e dar o IP 192.168.0.3 na interface virtual que vamos configurar para a mquina 192.168.0.2. Para o cliente que est solicitando o servio isso vai ser transparente, pois a mquina do com o IP final 1 caiu, mas a 2 assumiu e o cliente pede o servio para a mquina com final 3, que o nosso cluster e nunca direto para um dos nodos, ento indiferente de quem est trabalhando o IP 3 para o cliente efetuar a solicitao do servio vai ser sempre no endereo 3. Continuando. Clique em novamente em add parameter. Vai abrir uma nova tela, selecione em name a opo cidr_netmask e em value digite a mscara de rede para o seu cluster, exemplo 255.255.255.0. Clique novamente em add parameter. Vai abrir uma nova tela, selecione em name a opo nic e em value digite por exemplo eth0:1, que vai ser a placa de rede virtual para o nosso cluster, como expliquei acima, vai ser nessa interface que o Heartbeat vai dar o IP 192.168.0.3. Clique em novamente em add parameter.

Vai abrir uma nova tela selecione em name a opo broadcast e em value digite o broadcast da sua rede, exemplo 10.10.10.10.255. Depois disso clique em adicionar o final desta tela. Pronto, j temos o IP para o nosso cluster, se o servio que acabamos de configurar no subir sozinho, clique com o boto direito do mouse em cima dele e clique em start. Com isso j temos o nosso cluster bem simples. Obs.: Note que quando formos adicionar um novo recurso, temos vrias opes de servios, ento podemos configurar diversos tipos de servios como servidor de email, ssh etc. Porm o Heartbeat para o servio na mquina que no est sendo usada para no ficar ocupando processamento e memria, at a tudo bem, timo isso, mas se voc for usar o monit para monitorar os servios, eles vo viver brigando, pois o Heartbeat para o servio e o monit o inicia, ento quando for configurar os servios pelo Heartbeat, s se lembre disso se o Heartbeat e o monit estiverem trabalhando no mesmo servidor. Para eles no ficarem brigando, no monitore o servio que foi definido no Heartbeat. Ex.: Voc quer disponibilizar um cluster de correio eletrnico, ento voc monta o servidor de correio e coloca o Heartbeat nele para fazer o cluster e configura somente o endereo IP do recurso, neste caso todos os servios que o servidor1 estiver provendo, se estiverem configurados no servidor2, quando o servidor1 cair o servidor2 comea a prover todos os mesmos. Com isso podemos definir que no precisamos configurar mais recursos de servios para o Heartbeat se o que queremos um cluster total de 2 servidores e no somente de algum servio especfico, caso contrrio configure os recursos de servios para prover somente os recursos que desejar. Exemplo de incluso de um recurso de servio. Agora vamos adicionar um novo recurso, o servio do apache2. Clique com o boto direito do mouse em resources e clique em add new item. Escolha a opo native e clique em ok. Pronto, estamos na nossa tela de seleo de recursos, d um id para o seu recurso, como Apache2 e em recursos selecione o apache2. Note que neste recurso em Class/Provider ele LSB, este tipo de recurso no necessita de parmetros, ento s clicar em Adicionar no final da pagina. Pronto, j temos o nosso IP para o cluster e um servio. Mas e agora, em qual servidor o servio do apache vai estar funcionando? Por padro ele vai ficar rodando no servidor que voc conectou com o haclient. Mas podemos mudar isso, ento vamos adicionar um recurso do tipo location. Ex.: Tipos de aplicaes para isso. Voc tem um servidor BOM com uma tima configurao de hardware e um servidor mais fraco em cluster, ento para quem voc vai dar prioridade de servio? Eu daria prioridade para o servidor bom e deixaria o servidor mais fraco como servidor de contingncia, caso o primeiro pare o segundo assume. Neste tipo de situao esta aplicao de location muito til. Vamos a um exemplo de configurao de um location. Clique em Resources com o boto direito e selecione add new item. Selecione a opo location.

Na prxima tela informe o ID exemplo apache2 para o nosso location, que vai ser o local aonde o servio vai ter prioridade para trabalhar e como s temos um grupo s selecionar ok. Se tivssemos mais um grupo de servio, poderamos deixar cada grupo de servios em um servidor. Note que agora abaixo de resources temos Locations, clique em apache2 definido acima. Do nosso lado direito agora apareceu o nosso location, note que na parte inferior deste tela temos dois botes, um add expression e um delete expression. Clique em add expression. Na tela que vai abrir o primeiro atributo pode manter como #uname, o segundo atributo tambm pode manter como est e no terceiro atributo escolha um dos dois servidores no qual voc quer que tenha preferncia para rodar o servio do apache, da clique em ok. Pronto, j definimos as preferncias, note que na parte superior da tela temos um campo para digitar o score, essa opo que vai definir a prioridade de cada servidor. Para trabalhar com o servio do apache digite 100 e adicione agora um novo location e uma nova expression, selecione o segundo servidor e digite um valor de score menor. Pronto, agora j temos o nosso heartbeat funcionando. Vamos fazer alguns testes. Chame o seu navegador e digite: http://192.168.0.3 Se aparecer a tela do apache est ok. Se no apareceu, volte no artigo e configure tudo novamente para ter certeza que voc no esqueceu de nada. Agora vamos desligar a mquina que est com o score 100. Aps desligar a mquina, acesse novamente: http://192.168.0.3 Est funcionando maravilha! Olhe no console do heartbeat cliente que quem assumiu o servio foi o segundo nodo, que est com menor prioridade e caso no estivesse com menor prioridade o heartbeat iria subir ele da mesma forma, pois seria detectado que o primeiro nodo caiu. Mais um teste. Ligue novamente o nodo 1 o servidor que voc desligou. V na tela do haclient, assim que o nodo 1 voltar a ativa ele retoma o servio que estava com o nodo 2, pois ele tem score 100. E agora s ir inserindo recursos e testando, lembrando que os recursos do tipo LSB no precisam de parmetros e os outros recursos precisam, exemplo o recurso apache, ele muda de distribuio para distribuio o caminho do arquivo de configurao. Como eu falei no comeo, esse o caminho das pedras, agora vocs j podem ir testando o heartbeat e adaptando s suas necessidades.

Instalao e configurao do DRBD8 e OCFS2

Vamos instalar o drbd8. # aptitude install drbd8-modules-2.6-686 drbd8-utils ocfs2-tools ocfs2-tools-dev ocfs2console -y Aps instalarmos o nosso drbd vamos carregar os mdulos necessrios. # modprobe cn # modprobe drbd Vamos ao arquivo de configurao do drbd, este arquivo fica localizado em /etc/drbd.conf. # vim /etc/drbd.conf #/etc/drbd.conf # Opes Globais # Geralmente no incio do arquivo. Poucas opes so definidas nesta seo. # global { usage-count yes; # Gerar status da atualizao do sistema de DRBD. } # # Opes comuns a mais de um recurso, quando houver. No caso de existir opes # definidas internamente ao recurso, elas iro sobrepor as opes comuns. common { protocol C; # Mtodo de replicao. Neste caso, replicao sncrona. } ### ocfs2 usando 02 primrios resource r1 { net { # Permitir/habilitar dois servidores primrios. allow-two-primaries; #Permite habilitar dois servidores primrios after-sb-0pri discard-younger-primary; after-sb-1pri consensus; after-sb-2pri disconnect; } startup { # Iniciar os dois servidores como primrios, por padro. become-primary-on both; } syncer { rate 600M; #Para placas de rede de 10/100 utilizar 10M } on debian { device /dev/drbd1; # Nome do dispositivo de DRBD disk /dev/hda11; # Dispositivo de baixo nvel utilizado a partio address 192.168.0.1:7789; # IP:porta de conexo meta-disk internal; # Armazenamento das informaes de dados feito # dentro do dispositivo de baixo nvel. } on debian2 { device /dev/drbd1; disk /dev/hda11; address 192.168.0.2:7789; meta-disk internal;

} } Como pode ser visto, o arquivo est todo comentado e de fcil entendimento. O arquivo pode ser mantido como padro para configurao de outros servidores com DRBD + OCFS, somente mudando a seguinte parte do arquivo: on debian { device /dev/drbd1; # Nome do dispositivo de DRBD disk /dev/hda11; # Dispositivo de baixo nvel utilizado address 192.168.0.1:7789; # IP:porta de conexo meta-disk internal; # Armazenamento das informaes de dados feito # dentro do dispositivo de baixo nvel. } on debian2 { device /dev/drbd1; disk /dev/hda11; address 192.168.0.2:7789; meta-disk internal; } } Vamos agora criar os dispositivos do drbd. Obs.: Se voc no criou a partio para os nosso teste, pode fazer isso utilizando o cfdisk para criar a partio hda11. Ex.: # cfdisk /dev/hda Escolha o espao livre e crie uma partio de 2 GB para efetuarmos testes e mande gravar. Para um ambiente de produo a partio vai depender do volume de dados. Este nosso artigo somente um exemplo para a um ambiente de produo e anlise do que vai ser necessrio, por isso utilize Itil e cobit se possvel para obter um bom planejamento e execuo. Esses comandos que eu vou passar tem que ser executados nos dois servidores (comando a comando). Vamos zerar o dispositivo para ter certeza que no vai dar nem um problema. # dd if=/dev/zero of=/dev/hda11 bs=1M count=128 Pronto, a nossa partio est zerada. Execute este comando nos dois servidores antes de passar para o prximo comando. # drbdadm -- --discard-my-data connect r1 Onde r1 o nome do nosso dispositivo, que no arquivo de configurao do drbd est como resource r1. Execute este comando nos dois servidores antes de passar para o prximo comando. # drbdadm create-md r1 Execute este comando nos dois servidores antes de passar para o prximo comando. # drbdadm attach r1 Execute este comando nos dois servidores antes de passar para o prximo comando.

# drbdadm connect r1 Pronto, agora podemos iniciar o drbd, inicie-o nos dois servidores com o seguinte comando: # /etc/init.d/drbd start Podemos observar como est a situao do nosso dispositivo drbd com o seguinte comando. # cat /proc/drbd Se em "Connected st" estiver como Primary/Primary, est tudo ok, porm se estiver como Secondary/Secondary temos que forar os dispositivos a passarem para primary e temos mais uma situao quanto ao dispositivo Unknown, normalmente quando um dos servidores no est operante por problemas de rede ou de configurao do arquivo do drbd. Ento muita ateno a esses detalhes. Vamos levar em considerao que s estamos com o problema que os dois servidores esto como secondary, resolvemos com o seguinte comando. Este comando tem que ser rodado nos dois servidores. # drbdadm -- --overwrite-data-of-peer primary r1 Agora s esperar eles sincronizarem os dados, isso depende da placa de rede, da velocidade do disco e do tamanho do disco, fora os processos do drbd, se voc notar muita lentido em algum desses fatores, veja se no bom fazer algum upgrade. Para acompanhar a sincronizao pode utilizar o seguinte comando: # watch cat /proc/drbd Para sair s pressionar CTRL+C. Quando terminar a sincronizao vai aparecer depois de Primary/Primary em ds:Inconsistent/Inconsistent como: cs:Connected st:Primary/Primary ds:UpToDate/UpToDate Pronto, j temos um raid1 via rede. Ento para que o OCFS2? Como comentei no comeo do artigo, esse um dos sistemas de arquivos que podemos ter dois master escrevendo no sistema de arquivos no DRBD, somente o Primary poderia escrever, ento se o primary parasse teramos que montar a partio do que estava como secondary e usar o comando para mudar ele para primary para da sim ele poder escrever. Com o OCFS2 os 2 podem escrever simultaneamente, por isso que eu peguei o servidor de email para tratarmos por que o que me adianta eu ter 2 servidores de email sem as caixas de mensagens iguais? Poderamos utilizar o rsync para ir atualizando mais, dependendo do volume isso poderia se tornar invivel e teria que ser agendando de tempos em tempos. Ex.: O seu servidor de email caiu e o secundrio fazia o rsync das caixas de entrada a cada 30 minutos e o seu chefe est com uma mensagem para fechar um contrato muito importante nesse servidor que caiu e a mensagem chegou a cerca de 2 minutos, o rsync no sincronizou e o seu chefe vai jogar a culpa em quem? E pior, deu pau o HD desse servidor, e agora? Em uma empresa que recebe 100 emails por dia isso um pequeno erro.

Mas em uma empresa que recebe cerca de 100 mil emails por dia ou mais, isso seria uma catstrofe e a sua cabea iria rolar. Para no acontecer isso teramos o DRBD+OCFS2 trabalhando em conjunto, essa soluo poderia ser trocada por um STORAGE, mas um STORAGE no est muito barato e a maioria das empresas nem pensa em comprar um equipamento desses, ento o ADM que tem que se virar, por isso que estou escrevendo este artigo. Igualmente eu muitos outros ADMs esto precisando de uma soluo de alta disponibilidade dessas e sem gastar muito. Vamos l para o OCFS2. Lembra que instalamos o ocfs2console? Ento vamos precisar dele e voc tem as mesmas opes do haclient de exportar o ocfs2console via ssh ou o que voc preferir, oo utilizar o putty que o que eu uso. De acordo com a documentao oficial da Oracle, altamente recomendado que o arquivo que vem por padro em /etc/ocfs2/cluster.conf seja renomeado e que a configurao seja feita via console grfico. Ento chame o ocfs2console: # ocfs2console & Aps aparecer a tela do ocfs2console clique em Cluster/Configure Nodes. A configurao dos nomes das mquinas deve ser exatamente igual ao hostname das mesmas. Clique em Adicionar na tela que aparece e digite o nome da mquina como explicado acima. Digite o endereo IP no campo logo abaixo. E a porta pode deixar como o padro 7777. Clique em ok. Agora faa o mesmo processo para incluir o segundo nodo. Clique em Adicionar na tela que aparece, digite o nome da mquina como explicado acima. Digite o endereo IP no campo logo abaixo. E a porta pode deixar como o padro 7777. Clique em ok. Agora clique em aplicar. E pode clicar agora em fechar. Agora no servidor aonde voc exportou a tela de configurao do ocfs2console, v ao diretrio /etc/ocfs2 e vamos fazer uma cpia deste arquivo para o segundo servidor. # rsync -Hxpagouvt cluster.conf 192.168.0.2:/etc/ocfs2/ Pronto, j temos a configurao nos dois servidores. Precisamos de mais um ajuste. No debian temos que editar o arquivo /etc/default/o2cb e ativ-lo. Aonde que se encontra essa linha mude para true: O2CB_ENABLED=false # vim /etc/default/o2cb [...] O2CB_ENABLED=true [...] Pronto, agora podemos iniciar o servio. # /etc/init.d/o2cb stop

# /etc/init.d/o2cb start Se der algum erro verifique os logs para ver se no erro de sintaxe no /etc/default/o2cb. Se no deu erro timo, vamos continuar. Agora vamos formatar as nossas parties com o sistema de arquivos OCFS2. Vamos criar um diretrio chamado /ocfs2 nos dois servidores que precisaremos deles logo. # mkdir /ocfs2 Acesse novamente o console do ocfs2. # ocfs2console & V em Tasks/Format... vai abrir uma nova tela, nela vo informar os devices, no nosso caso o /dev/drbd1. Em Label coloque o nome que achar mais conveniente, como Cluster ou Oracle. Em cluster size deixe com 128k, que o volume de armazenamento de dados, em geral em Number of node slots coloque 2, que o nosso nmero de nodos. Em block size 4k. E s clicar em Ok. s esperar formatar. Agora vamos montar a nossa partio. No console temos um boto de mount, clique nele. Vai aparecer uma tela pedindo o ponto de montagem e as opes. Em ponto de montagem selecione a partio que criamos /ocfs2 e em options coloque como defaults e clique em ok. Acesse o outro servidor e monte na mo a outra partio com: # mount.ocfs2 /dev/drbd1 /ocfs2 Utilize o "df -Th" para ver as parties e os tamanhos ou o comando mount. Eu prefiro o "df -Th", pois d para ver a partio, o ponto de montagem, o sistema de arquivos em forma mais legvel que o mount. # df -Th /dev/drbd1

ocfs2

2G 45M

2G

2% /ocfs2

Para efetuar testes entre na partio /ocfs2 e crie um arquivo ou um diretrio e v no outro servidor e adicione mais um e confira se os dois servidores conseguem acessar estes arquivos ou diretrios. Ex.: Em um dos servidores faa o seguinte: # mkdir /ocfs2/teste Criamos um diretrio chamado teste, agora vo ao outro servidor e vamos criar um arquivo dentro deste diretrio teste. No outro servidor: # touch /ocfs2/teste/tudook

Note que temos acesso nos dois servidores ao mesmo arquivo, que o nosso propsito e melhor, podemos criar e excluir simultaneamente os arquivos e diretrios. Isso bom demais! Agora que j temos tudo certo vamos colocar esta partio para ser montada na inicializao do sistema. Vamos editar o arquivo /etc/fstab # vim /etc/fstab [...] /dev/drbd1 /ocfs2 _netdev,defaults 0 0 Pronto, criamos uma entrada no arquivo de montagem na inicializao do sistema, este parmetro que coloquei _netdev para ser montada a partio depois que subir a rede, pois no adianta ele tentar montar sem rede pois seno de que vai adiantar o /ocfs2, ele vai ser uma partio local como um /var ou /etc. Agora vamos acertar um problema que achei na inicializao, no Debian GNU/Linux por padro o drbd inicializa depois do ocfs2, isso est errado pois o que o ocfs2 vai gerenciar se o dispositivo do drbd no esta ativo? Ento vamos arrumar isso. Faa isso nos 2 servidores. # mv /etc/rc2.d/S70drbd /etc/rcS.d/S50drbd Agora vamos ver se ficou tudo certo : # ls /etc/rcS.d/ S50drbd S55bootmisc.sh S55urandom S60o2cb S65ocfs2 Note que agora o drbd vai inicializar antes do o2cb e do o2cfs, que so quem gerenciam o ocfs2. Agora vai tudo funcionar corretamente. Para fazer um teste reinicialize os dois servidores e veja se o /ocfs2 vai inicializar normalmente. Se estiver tudo certo no vai dar nem um problema. Se der algum problema tente identificar nos arquivos de log do sistema como o comando "dmesg" e os arquivos /var/log/syslog e /var/log/messages.

LVS
Algumas consideraes. Como no comeo eu passei 3 mquinas para trabalho e vocs notaram que ns fizemos um cluster de 2 mquinas, ento elas passaram de 2 para 1 correto? Exemplo: Quando o cliente vai solicitar o servio do Apache ele no pede para o servidor debian1 ou debian2, ele pede para o cluster que tem o IP 192.168.0.3. Ento como que vamos fazer o balanceamento de somente uma mquina? No tem como. Ento para este exemplo precisamos de no mnimo 3 mquinas ou uma mquina e 2 clusters para fazermos o balanceamento. Ou pegue mais uma mquina fora as duas do cluster, pare o Heartbeat dos servidores para podermos utilizar as mquinas sem o cluster para vermos como que tudo funciona, bem simples. Vamos configurar primeiro o arquivo /etc/sysctl.conf da mquina que vai trabalhar como servidor de LVS e acrescente a seguinte linha no final do arquivo. # vim /etc/sysctl.conf [...] net.ipv4.ip_forward = 1 Utilize o seguinte comando para salvar as alteraes no arquivo: # sysctl -p Vamos instalar os pacotes no servidor LVS. # aptitude install ldirectord-2 -y Pode confirmar a instalao dos pacotes sugeridos. Agora vamos configurar os clientes. a mesma configurao para os 2 clientes. Edite o arquivo /etc/sysctl.conf e adicione as linhas como no exemplo: # vim /etc/sysctl.conf [...] #Habilita a opo de ignorar ARP net.ipv4.conf.all.arp_ignore = 1 #Ignora requisio de ARP se a requisio for feita para interface lo ou qualquer interface virtual (eth0:x) net.ipv4.conf.eth0.arp_ignore = 1 #Habilita a opo de anuncio de ARP.

net.ipv4.conf.all.arp_announce = 2 #Evitar o anuncio do endereo de origem no cache da tabela de ARP de destino. #indesejado para interface lo e virtuais net.ipv4.conf.eth0.arp_announce = 2 Vamos salvar as nossas alteraes. # sysctl -p Agora vamos voltar para o servidor e vamos configur-lo para fazer o balanceamento. # vim /etc/ha.d/conf/ldirectord.cf #Arquivo de configurao principal do LVS. #/etc/ha.d/conf/ldirectord.cf #tempo em segundos, ate declarar que o servidor caiu. checktimeout=2 #Tempo em segundos de checagem entre os servidores. checkinterval=4 #Recarregar o servio automaticamente caso o arquivo de configurao seja alterado. autoreload=yes #Arquivo dos logs do Ldirectord logfile="/var/log/ldirectord.log" #email valido para envio de informaes de erro do subsistema emailalert="ti@lan.com.br" #Tempo em segundos para repetir a mensagem de alerta por email emailalertfreq=3600 #definir como yes, quando um servidor real cair ele no ser eliminado da lista do subsistema quiescent=yes #Definio dos servidor LVS. #Interface virtual compartilhada e porta do servido. #Nota. Cada diretiva, a partir da virtual, deve iniciar com e no com espaos virtual=192.168.0.4:80 fallback=127.0.0.1:80 #Endereo de resposta caso todos falhem real=192.168.0.1:80 gate #servidor real e porta. roteamento direto real=192.168.0.2:80 gate #servidor real e porta. roteamento direto service=http #Servio para balanceamento. request=".testpage" #arquivo de requisio para teste. receive="test page" #contedo do arquivo, resposta a receber scheduler=wlc #algoritmo de monitoramento. protocol=tcp #Protocolo utilizado checktype=negotiate #negocia a requisio e a resposta Agora temos que criar o arquivo .testpage, que ser o arquivo que o lvs iria fazer um get e conferir para ver se o servidor est ativo e o contedo o arquivo tem que ser test page. Vamos criar o arquivo: # vim /var/www/.testpage

test page O nosso arquivo agora est criado e com o contedo que definimos no lvs, vamos seguir. Obs.: Algoritmos de monitoramento podem ser encontrados no manual do ipvsadm(8). O algoritmo wlc o padro, ele envia mais servios ao servidor que possui menor carga e/ou o que for mais robusto. Agora vamos configurar os servidores de servio. Crie uma placa de loopback virtual com o endereo IP 192.168.0.4/255.255.255.255 em cada um dos servidores de servio. Para que isso? Se voc estiver usando o LVS, ento os pacotes que chegam ao servidor-real possuem o IP de destino definidos para o servidor LVS. Ento o servidorreal precisa de um meio de aceitar este trfego como local. Uma forma adicionar uma interface no dispositivo de loopback e escond-la, assim ela no responder as requisies ARP. A mscara deve ser 255.255.255.255 porque a interface de loopback ir responder aos pacotes para _todos_ os hosts em qualquer interface configurada. Assim 192.168.0.4 com mscara de rede 255.255.255.0 far com que a mquina aceite pacotes de _todos_ os endereos na faixa 192.168.0.0 - 10.10.10.255, o que na verdade no o que voc quer. Ento vamos configurar. # ifconfig lo:0 192.168.0.4 netmask 255.255.255.255 Pronto, agora podemos iniciar o LVS e testar. # /etc/init.d/ldirectord stop # /etc/init.d/ldirectord start Se ocorrer algum erro, olhe nos arquivos de log para tentar identificar algum erro no arquivo de configurao, olhe sempre no arquivo de log do ldirectord e no syslog. Agora para testar modifique a pgina inicial do Apache de cada servidor de servio para podermos diferenciar os dois exemplos: Digite o IP de cada servidor no arquivo index.html em /var/www/index.html. # vim /var/www/index.html [...] <h1>Servidor 10.10.10.251</h1> E faa o mesmo no segundo servidor. Depois de tudo modificado acesse o servidor 192.168.0.4 no navegador. Note que ele est acessando um dos dois servidores e no o servidor local. Pressione F5 para dar um refresh na pgina e note que j est acessando o outro servidor. Para mais informaes sobre o LVS, leiam a documentao do LVS que no comeo do artigo eu mencionei. Para visualizar no servidor de LVS como que esto os servios, digite o seguinte comando: # ipvsadm

Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight TCP 192.168.0.4 wlc -> 192.168.0.1 route 1 -> 192.168.0.2 route 1

ActiveConn 0 0

InActConn 0 0

Na visualizao temos que o Forward define o tipo de balanceamento, neste caso, roteamento direto. Weitht define se o servidor real est acessvel (1) ou no (0). ActiveConn e InActconn definem, respectivamente, as conexes ativas e os pacotes que esto entrando em conexo com o servio. Procurem mais documentaes a respeito deste assunto que bem bacana para balanceamento de carga.

Instalao e configurao do Monit

Vamos agora instalar o monit. O monit utilitrio de gerenciamento e monitoramento de processos, arquivos, diretrios, dispositivos e servios. Parecido com o Nagios, porm ele pode tomar aes nos servios, arquivos, processos, diretrios e dispositivos. Exemplo: o monit fica monitorando o Apache, se ele percebe que o Apache parou ento ele tenta reiniciar o servio, caso no consiga ele envia um alerta para o seu email lhe avisando que o Apache no pode ser iniciado. Voc pode fazer isso para qualquer servio, fazer monitoramento em arquivos para quando os arquivos sejam modificados o servio seja restartado ou seja enviado um email para voc avisando que o arquivo foi modificado, pode ser monitorado parties para no deixar elas sobrecarregadas, podemos monitorar as permisses de arquivos. Essa ferramenta muito boa e para mais informaes a respeito de configurao do monit podem ser encontradas nos seguintes endereos:

Configuraes gerais Exemplo de configuraes de servios

Ento vamos instalar o Monit em cada mquina, o arquivo de configurao vai depender de cada mquina e dos servios que ela tem. Estou colocando um arquivo de exemplo abaixo com alguns servios. O monit bem chato com a configurao dele, caso tenha algum erro na configurao voc no vai conseguir acessar a interface web. Ento preste bem a ateno na configurao e os servios que voc no estiver utilizando deixe comentados ou retire do arquivo. # aptitude install monit Temos que habilitar o arquivo /etc/default/monit e tem que mudar: startup=0 Para: startup=1 Agora vamos configura o monit. O arquivo de configurao se encontra em /etc/monit/monitrc. Faa um backup deste arquivo antes de comear edit-lo. A configurao dele bem simples. # vim /etc/monit/monitrc #Iniciar o monit em background (como daemon) set daemon 60 #Especificar o arquivo e categoria de log set logfile /var/log/monit.log #Receber todos os sistemas do alert

set alert ti@dominio.com #Receber somente alertas de timeout set alert gerenteti@dominio.com only on { timeout} #Definio do acesso ao monitoramento grfico #aqui definimos a porta a ser acessada no navegador a 2812 o endereo 192.168.0.1 #a rede que pode acessar 10.10.10.0/24 # o usuario=admin e a senha=monit set httpd port 2812 and use address 192.168.0.11 allow 192.168.0.0/24 allow admin:monit #Definio dos servidores de correio #definio do usurio que vai ser usado para o envio de emails e a senha set mailserver localhost username "monit@dominio.com" password "senha" with timeout 15 seconds #Caso no precise de autenticao pode ser usado da seguinte maneira para utilizar esta maneira de envio de email #comente a configurao do servidor de correio acima e descomente a logo abaixo #set mailserver localhost #Definio do modelo de email gerado set mail-format { from: monit@dominio.com subject: $SERVICE $EVENT at $DATE message: Monit $ACTION $SERVICE at $DATE on $HOST: $DESCRIPTION. Yours sincerely, Monit } set eventqueue basedir /var/spool/monit #Diretorio Base slots 100 #Limite de quantidade de eventos ######################PROCESSOS############################### #Processos que vao ser monitorados na mquina local check system xerxes.dominio.com if loadavg (1min) > 4 then alert if loadavg (5min) > 2 then alert if memory usage > 75% then alert if cpu usage (user) > 70% then alert if cpu usage (system) > 30% then alert if cpu usage (wait) > 20% then alert #######################DEVICES############################### #Aqui eu estou monitorando o drbd para que ele no exploda. #voc pode fazer o monitoramento de qualquer outra partio como eu j estava explicando o drbd+ocfs2 #vou monitorar eles. check device drbd1 with path /dev/drbd1 start program = "/bin/mount /dev/drbd1 /ocfs2" stop program = "/bin/umount /ocfs2" if space usage > 90% then alert if space usage > 95% then stop if inode usage > 90% then alert if inode usage > 95% then stop #Aqui estamos fazendo a checagem das permisses do diretrio /bin que contem os aplicativos #Validando o uid e gid dos arquivos e as permisses. check directory bin with path /bin if failed permission 755 then unmonitor

if failed uid 0 then unmonitor if failed gid 0 then unmonitor ######################ARQUIVOS############################### #Aqui eu estou controlando as modificaes dos arquivos de configurao #sempre que o arquivo de configurao for modificado o servio ser reiniciado. #Para recarregar a configurao. check file apache2.conf with path /etc/apache2/apache2.conf group www if changed checksum then exec "/etc/init.d/apache2 graceful" check file main.cf with path /etc/postfix/main.cf if changed checksum then exec "/etc/init.d/postfix restart" check file postfix_rc with path /etc/init.d/postfix group mail if failed checksum then unmonitor if failed permission 755 then unmonitor if failed uid root then unmonitor if failed gid root then unmonitor check file monitrc with path /etc/monit/monitrc if changed checksum then exec "/etc/init.d/monit restart" check file named.conf with path /etc/bind/named.conf if changed checksum then exec "/etc/init.d/bind9 restart" check file named.conf.options with path /etc/bind/named.conf.options if changed checksum then exec "/etc/init.d/bind9 restart" check file if failed if failed if failed if failed cron_rc with path /etc/init.d/cron checksum then unmonitor permission 755 then unmonitor uid root then unmonitor gid root then unmonitor

check file clamavd_rc with path /etc/init.d/clamav-daemon group Virus if failed checksum then unmonitor if failed permission 755 then unmonitor if failed uid root then unmonitor if failed gid root then unmonitor check file clamavd_bin with path /usr/sbin/clamd group Virus if failed checksum then unmonitor if failed permission 755 then unmonitor if failed uid root then unmonitor if failed gid root then unmonitor check file mysql_rc with path /etc/init.d/mysql group database if failed checksum then unmonitor if failed permission 755 then unmonitor if failed uid root then unmonitor if failed gid root then unmonitor check file mysql_bin with path /usr/sbin/mysqld group database

if if if if

failed failed failed failed

checksum then unmonitor permission 755 then unmonitor uid root then unmonitor gid root then unmonitor

check file spamd_rc with path /etc/init.d/spamassassin group mail if failed checksum then unmonitor if failed permission 755 then unmonitor if failed uid root then unmonitor if failed gid root then unmonitor check file spamd_bin with path /usr/sbin/spamd group mail if failed checksum then unmonitor if failed permission 755 then unmonitor if failed uid root then unmonitor if failed gid root then unmonitor #####################SERVIOS############################### #aqui o monitoramento de servios. #no qual checamos os pid para ver se existem caso no existam #vamos iniciar o servio #e podemos fazer a verificao de portas e protocolos exemplo o apache2 logo abaixo check process apache2 with pidfile "/var/run/apache2.pid" start program = "/etc/init.d/apache2 start" stop program = "/etc/init.d/apache2 stop" if failed port 80 and protocol http then restart group www check process sshd with pidfile "/var/run/sshd.pid" start program = "/etc/init.d/ssh start" stop program = "/etc/init.d/ssh stop" if failed port 22 and protocol ssh then restart check process cron with pidfile "/var/run/crond.pid" start program = "/etc/init.d/cron start" stop program = "/etc/init.d/cron stop" if 5 restarts within 5 cycles then timeout check process ntp with pidfile /var/run/ntpd.pid start program = "/etc/init.d/ntp start" stop program = "/etc/init.d/ntp stop" if failed port 123 type udp then alert if 5 restarts within 5 cycles then timeout check process rsyslogd with pidfile /var/run/rsyslogd.pid start program = "/etc/init.d/rsyslog start" stop program = "/etc/init.d/rsyslog stop" if 5 restarts within 5 cycles then timeout check process named with pidfile /var/lib/named/var/run/bind/run/named.pid start program = "/etc/init.d/bind9 start" stop program = "/etc/init.d/bind9 stop" if failed host 127.0.0.1 port 53 type tcp protocol dns then alert if failed host 127.0.0.1 port 53 type udp protocol dns then alert if 5 restarts within 5 cycles then timeout #Exemplo de servio que vai ser monitorado se outro estiver ok #a clusula depends on postfix_rc serve para definir que este servio s vai ser monitorado caso #o postfix_rc estiver trabalhando, caso contrario este servio no vai ser monitorado. check process postfix with pidfile /var/spool/postfix/pid/master.pid start program = "/etc/init.d/postfix start"

stop program = "/etc/init.d/postfix stop" if failed port 25 protocol smtp then restart if 5 restarts within 5 cycles then timeout depends on postfix_rc group mail #aqui temos um exemplo de servio que s vai ser monitorado caso os arquivos clamavd_rc e clamavd_bin estiverem ok. check process clamav with pidfile /var/run/clamav/clamd.pid start program = "/etc/init.d/clamav-daemon start" stop program = "/etc/init.d/clamav-daemon stop" if 5 restarts within 5 cycles then timeout depends on clamavd_rc depends on clamavd_bin group Virus check process mysql with pidfile /var/run/mysqld/mysqld.pid group database start program = "/etc/init.d/mysql start" stop program = "/etc/init.d/mysql stop" if failed host 127.0.0.1 port 3306 protocol mysql then restart if 5 restarts within 5 cycles then timeout depends on mysql_rc depends on mysql_bin check process spamd with pidfile /var/run/spamd.pid group mail start program = "/etc/init.d/spamassassin start" stop program = "/etc/init.d/spamassassin stop" if 5 restarts within 5 cycles then timeout if cpu usage > 99% for 5 cycles then alert if mem usage > 99% for 5 cycles then alert depends on spamd_rc depends on spamd_bin #####################Heartbeat2############################ #Aqui estou monitorando o meu segundo nodo do heartbeat s para saber se ele esta funcionando. check host esparta with address 10.10.10.252 if failed icmp type echo count 3 with timeout 3 seconds then alert if 5 restarts within 5 cycles then timeout Agora que j instalamos e configuramos o monit, temos que reinici-lo para que ele releia o arquivo de configurao, e como que comentei no comeo, deixe no arquivo de configurao somente os servios que voc tem no servidor, seno o monit no vai funcionar. Vamos reinici-lo. # /etc/init.d/monit stop # /etc/init.d/monit start Se deu tudo certo podemos acessar a interface grfica pelo endereo do servidor:porta que est configurado no arquivo. Exemplo: http://192.168.0.1:2812 Ele vai pedir o usurio: admin E a senha:monit Pronto, aqui temos a interface do monit. Ele bem simples, para habilitar ou desabilitar algum monitoramento s clicar no link do nome do monitoramento e efetuar o gerenciamento parando, iniciando, reiniciando, desabilitando ou habilitando o monitoramento.

O resto s acompanhar os arquivos de log. Obrigado pela leitura! Tomara que eu tenha ajudado! Qualquer dvida fico a disposio. Douglas Q. dos Santos. msn: quintilianodouglas@hotmail.com email: douglashx@gmail.com