Configuração pelo modo texto
============================
Por: Luis Claudio R. Gonçalves (lclaudio at conectiva dot com dot br)
Rascunho do texto para o manual do CL9, edição Servidor.


Definição dos Recursos
----------------------

Edite o arquivo /etc/ha.d/haresources.

Este arquivo contém uma lista dos serviços que serão gerenciados pelo heartbeat,
dos endereços IP a serem utilizados e de quem é o servidor primário para cada
grupo de serviços.

Exemplo:

# /etc/ha.d/haresources
#nome-do-nodo  IP-virtual  recurso1  recurso2 ... recursoN
ha1 10.0.17.26 datadisk httpd mysql

Detalhes importantes a respeito desta configuração:

- O "nome-do-nodo" deve ser o nome retornado pela execução do comando 'uname -n'
  em cada um dos nodos citados no arquivo.

- Os endereços IP listados neste arquivo não devem ser endereços fixos de
  nenhuma máquina na rede. Estes endereços serão adicionados às interfaces
  corretas, pelo heartbeat, quando os serviços forem iniciados num dos nodos.
  São os chamados "endereços virtuais" citados na documentação que acompanha
  o heartbeat.

- Os recursos são inicializados na ordem em que são listados, recebendo o
  parâmetro "start". São finalizados em ordem inversa, com o parâmetro "stop".

- Estes recursos devem comportar-se como initscripts SystemV (scripts de
  inicialização de serviços), respeitando o padrão LSB para códigos de retorno
  das operações start, stop e status.

- Os recursos podem ser outros endereços IP virtuais,


Configuração do cluster
-----------------------

O arquivo responsável pela configuração do cluster é /etc/ha.d/ha.cf. 

Segue abaixo um exemplo de arquivo de configuração, com as principais opções
devidamente configuradas e comentadas. O arquivo de exemplo que acompanha o
heartbeat possui outras opções mais avançadas, mas desnecessárias para a vasta
maioria das configurações.

Das várias possibilidades de configuração do arquivo ha.cf, o indispensável é um
conjunto de nodos ("node ...") e uma ou mais interfaces ("serial, bcast, mcast
ou ucast").

Excetuando-se a configuração ucast que é diferente nos dois nodos e as
configurações de porta serial, que podem ser diferentes, o arquivo ha.cf
é igual nos dois nodos.

Segue o arquivo de exemplo:

# /etc/ha.d/ha.cf

# Arquivo para mensagens de depuração (debug)
#debugfile /var/log/ha-debug
#
# Arquivo para armazenar mensagens gerais do cluster
#logfile	/var/log/ha-log

# Enviar mensagens de log e mensagens gerais para o syslog
# (pode ser utilizado em conjunto com as opções acima).
logfacility	local0

# Os tempos podem ser especificados em segundos ou milissegundos.
# A unidade padrão é segundos.
# Exemplos:
#          10          significa dez segundos
#          1500ms      significa 1,5 segundos

# keepalive: tempo entre heartbeat (sinais de vida)
keepalive 3

# deadtime: tempo para declarar o nodo como inoperante
deadtime 30

# warntime: quanto tempo esperar antes de emitir o aviso de "late heartbeat"
#           (heartbeat atrasado). Verifique na FAQ como utilizar este
#           parâmetro para melhor ajustar o deadtime.
#warntime 10

# initdead: deadtime na inicialização do heartbeat.
#
# Em alguns casos a rede leva algum tempo para tornar-se operante
# após uma reinicialização do sistema. Para estes casos, existe um
# parâmetro (initdead) para controlar o deadtime na inicialização
# do heartbeat. Sugere-se que ele seja no mínimo 2*deadtime.
#initdead 120



# nice_failback: determina o comportamento do cluster com relação
#                aos recursos.
#
# O comportamento padrão, equivalente a "nice_failback off", é que
# enquanto o servidor declarado como primário para um grupo de recursos
# estiver operante, os recursos estão com ele. Caso ele retorne de uma
# falha, os serviços retornam para ele (failback).
#
# Com "nice_failback on", caso o servidor secundário esteja executando os
# serviços e o servidor primário (segundo a configuração) retorne, os serviços
# continuam sendo prestados pelo secundário até que este torne-se inoperante.
#nice_failback on

# Comunicação
#
# udpport: porta udp utilizada para comunicação (694 é o padrão)
udpport	694

# Interfaces para o envio de heartbeats
#
# bcast: envia heartbeats por broadcast (comportamento padrão das versões
#        anteriores).
bcast eth0

# ucast: envia heartbeats para um endereço IP específico
#        Uso: ucast interface IP-do-outro-nodo
#ucast eth0 192.168.1.2

# mcast: envia heartbeats para um grupo de multicast
#	 Uso: mcast [dev] [mcast group] [port] [ttl] [loop]
#
#	[dev]		dispositivo para envio e recepção de heartbeats
#	[mcast group]	grupo de multicast a usar (end. multicast classe D
#			224.0.0.0 - 239.255.255.255)
#	[port]		porta udp para envio e recepção de heartbeats. Pode
#			ser a mesma usada nos exemplos de bcast e ucast.
#	[ttl]		propagação dos pacotes (heartbeats) enviados. (0-255)
#	[loop]		recebe (1) ou não (0) os próprios heartbeats.

# serial: porta serial utilizada para envio de heartbeats
#
# Consulte a documentação do pacote para maiores informações sobre a
# confecção de cabos e outros detalhes.	
# Uso: serial porta
#serial	/dev/ttyS0

# baud: velocidade (baud rate) da porta serial...
#baud	19200

# node: lista os nodos do cluster
#       (contém o nome retornado por uname -n)
node	ha1
node	ha2


Chaves de autenticação de mensagens
-----------------------------------

Estas opções são configuradas no arquivo /etc/ha.d/authkeys.

Deve-se selecionar uma das três possibilidades de autenticação de mensagens,
crc, sha1 ou md5. As duas últimas pedem uma chave para ser usada na
autenticação.

O arquivo authkeys deve possuir direitos de leitura e escrita apenas para root.
Isso pode ser assegurando executando-se:

chmod 600 /etc/ha.d/authkeys

Segue um exemplo de arquivo de configuração:

# /etc/ha.d/authkeys
#
#auth 1
#1 crc
#2 sha1 chave
#3 md5 chave
auth 2
sha1 mahnamahna

