Alta disponibilidade é uma solução de cluster que possibilita que um serviço fique mais tempo disponível.

Muitos definem cluster como sendo um conjunto de servidores agrupados com intenção de ganho de desempenho ou disponibilidade.

Segundo Pitanga (2003), no ano de 1994 o primeiro projeto de cluster foi realizado pela NASA.

Os clusters normalmente são compostos por máquinas convencionais ligadas em rede oferecendo abstração para o usuário utilize apenas uma única máquina.

O cluster de alta disponibilidade tem a intenção de manter a maior disponibilidade possível dos serviços, através da duplicação de servidores e recursos.

O funcionamento basicamente é baseado em um sistema de monitoração interna no cluster, que em caso de falha do servidor ativo, aciona automaticamente o servidor standby.

O serviço de alta disponibilidade envolve os seguintes recursos:

• Redundância de estrutura;
• Camada de software de monitoração;
• Mecanismo de sincronia.

A nossa tarefa agora é implementar um serviço de OpenLDAP que atenda esses recursos de alta disponibilidade.

A figura 1 mostra o modelo que estaremos tratando nesse artigo. Os clientes acessam o OpenLDAP através de uma interface virtual.

Enquanto o heartbeat estiver ativo, o servidor master estará ativo, porém quando heartbeat parar o servidor slave assumira o controle e a interface virtual estará apontando para o slave.

Figura 1 – Esquema do OpenLDAP com HA

Um elemento fundamental para o sucesso da alta disponibilidade é a parte da replicação dos dados do LDAP master para o LDAP slave.

Pode-se pensar em várias possibilidades, entre as quais podemos destacar.

• DRBD: Pode-se usar o DRBD para fazer a replicação dos dados, porém essa ferramenta forçaria que o LDAP estive-se parado no slave.
• Syncrepl: Pode-se utilizar replicação master – slave; esse recurso é bem interessante porque o slave fica disponível para consulta mas trás o problema no failback.
• Rsync: pode-se também utilizar o rsync para enviar os arquivos ldifs da base LDAP, porém existe o mesmo problema do DRDB.
• N-Way Multimaster: Esse recurso usa o rsync para fazer replicação master – master. Esse recurso é muito importante porque mantém o slave ligado para consulta e resolver o problema do failback.

A primeira coisa a fazer é instalar o OpenLDAP e configurá-lo para replicação master – master.

Antes da configuração do slapd.conf, ajuste os hosts do servidor master e slave. Neste caso serão utilizados os seguintes nomes e ip. O hostname das maquinas deve estar dessa forma.

Server1     10.0.0.90 (Master)
Server2    10.0.0.91  (Slave)
LDAP        10.0.0.99 (IP Virtual)

Com esses dados podemos configurar o arquivo slapd.conf. Segue a configuração slapd.conf do servidor master.

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/misc.schema

password-hash {CRYPT}
defaultsearchbase dc=nisled,dc=org

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

loglevel 1024

modulepath /usr/lib/ldap
moduleload back_bdb
moduleload back_monitor
moduleload syncprov

database monitor
database bdb
cachesize 5000
mode 0600

suffix "dc=nisled,dc=org"
rootdn "cn=manager,dc=nisled,dc=org"
rootpw pedra

index default sub
index uid,mail eq
index entryCSN      eq
index entryUUID eq
directory "/var/lib/ldap"

lastmod on

# provedor
serverID 001
syncrepl rid=001
provider=ldap://server2:389
searchbase="dc=nisled,dc=org"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=manager,dc=nisled,dc=org"
credentials=pedra
type=refreshAndPersist
retry="5 + 5 +"
interval=00:00:00:05

mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10

Após a configuração do master também configure o slave. Lembre-se de ajustar os hostname e os ip da maquina slave.

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/misc.schema
password-hash {CRYPT}

defaultsearchbase dc=nisled,dc=org
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel 1024

modulepath /usr/lib/ldap
moduleload back_bdb
moduleload back_monitor
moduleload syncprov

database monitor
database bdb
cachesize 5000
mode 0600
suffix "dc=nisled,dc=org"
checkpoint 512 720
rootdn "cn=manager,dc=nisled,dc=org"
rootpw pedra

index default sub
index uid,mail eq
index entryCSN         eq
index entryUUID         eq

directory "/var/lib/ldap"
lastmod on

#replicacao
serverID 002
syncrepl rid=002
provider=ldap://server1:389
searchbase="dc=nisled,dc=org"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=manager,dc=nisled,dc=org"
credentials=pedra
type=refreshAndPersist
retry="5 + 5 +"
interval=00:00:00:05

mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10

Com essa configuração a replicação do LDAP master – master deverá está funcionando corretamente.

O próximo passo é configurar o programa heartbeat. Esse programa tem basicamente a função de mudar o "ip virtual" da maquina master para o slave quando ocorrer um problema no servidor master.

O heartbeat funciona enviado pacotes entre duas interfaces que pode ser rede ou serial. Caso o heartbeat do slave pare de receber os pacotes, ele assume que o master está com problema e aciona os recursos programados.

Para o heartbeat será utilizado outra interface (eth1) de rede que neste caso são as seguintes:

server1    192.168.100.1
Server2     192.168.100.2

A configuração do heartbeat envolve basicamente 3 arquivos que são eles:

• ha.cf
• haresources
• authkeys

No arquivo ha.cf é definido todos os parâmetros de transferência dos pacotes entre o master e o slave. Já no arquivo haresources é definido todos os recursos que serão iniciados quando o slave assumir. E no arquivo authkeys define o método de autenticação entre os hosts.

Os arquivos basicamente são iguais nos servidores.

Segue o arquivo ha.cf:

Debugfile        /var/log/ha-debug
logfile          /var/log/ha-log
logfacility        local0
keepalive        2
deadtime        30
warntime        10
initdead        120
udpport        694
ucast    eth1    192.168.100.2
node            server1
node            server2
auto_failback        on

No arquivo haresources basicamente ativa o "IP Virtual".

Segue o arquivo haresources:

server1 IPaddr::10.0.0.99/24/eth0

Essa configuração deverá ativar o "IP Virtual" 10.0.0.99 na interface eth0 no server1.

Já no arquivo authkeys é o método de autenticação.

Segue o arquivo authkeys:

auth 1
1 crc

Essas configurações é para o master, porém a configuração do slave é a mesma exceto no arquivo há.cf que devemos mudar a seguinte linha.

ucast    eth1    192.168.100.1

Com a configuração pronta, podemos testar o heartbeat da seguinte forma:

• Inicieo o heartbeat no master e no slave;
• Perceba que o IP Virtual tá no computador master;
• Pare o heartbeart no master;
• Perceba que o IP Virtual agora tá configurado no slave.

Dessa forma podemos disser que o heartbeat está configurado e funcionando.

Entretanto o serviço ainda não está terminando, imagine que o slapd do master parou ou simplesmente a conexão com a interface 10.0.0.90 (eth0) parou.

O heartbeat vai continuar comunicando com o slave através da interface eth1 (192.168.100.1), dessa forma o slave não ira assumir o serviço.

Para resolver esse problema usamos a ferramenta mon no servidor master. Com ela podemos monitorar tanto a conexão com aplicação. Se eles apresentarem problema, o mon desativa o heartbeat fazendo o slave assumir os serviços.

A configuração do mon se resumiu na edição do arquivo mon.cf.

alertdir=/usr/lib/mon/alert.d
mondir=/usr/lib/mon/mon.d
randstart=60s

hostgroup ldapserver 10.0.0.90

watch    ldapserver
service    ldap
interval     20s
monitor ldap.monitor -basedn "dc=nisled,dc=org" -filter "uid=clodonil" -attribute    uid    -value    clodonil
period
numalerts    2    
alert    heartbeat.alert
alert    mail.alert -S "Problema com servidor OpenLdap" clodonil@nisled.org

upalert    heartbeat.alert
upalert mail.alert -S "Servidor OpenLdap esta ok" clodonil@nisle.dorg

service    ping
interval    1m
monitor    fping.monitor
period
     numalerts    2
alert    heartbeat.alert
alert     mail.alert -S "Link ta com problema" clodonil@nisled.org

upalert    heartbeat.alert
upalert mail.alert -S "Link ta OK" clodonil@nisled.org

Agora temos o sistema completo. Se LDAP ou a conexão apresentarem problema o slave assumira o serviço. O mais interessante que o administrador vai receber um email informando que o sistema parou ou voltou. E quando voltar, após uma parada, o master ira receber os dados do slave devido a replicação master-master.