Montar un servidor LDAP en alta disponibilidad plantea enseguida la misma necesidad: algo que reciba las peticiones de los clientes y las reparta entre los nodos del servicio. Cuando hablamos de alta disponibilidad nos referimos a un entorno cuyo objetivo es mantener el servicio siempre disponible, y para eso es imprescindible que corra en más de un servidor: si uno de los equipos del clúster falla, los usuarios finales no deberían notarlo.
Esta guía recorre una configuración de balanceo de carga con HAProxy delante de dos nodos de Oracle Internet Directory, y la prueba de que el failover funciona de verdad.
Los nombres de host de los ejemplos están sustituidos por equivalentes genéricos.
El escenario
- Equipo HAProxy —
haproxy.ejemplo.local:389 - Nodo LDAP 1 —
ldap01.ejemplo.local:3060 - Nodo LDAP 2 —
ldap02.ejemplo.local:3060
Los clientes apuntarán al puerto LDAP estándar (389) del equipo HAProxy, que redirigirá cada petición a uno de los dos nodos.
1. Instalar HAProxy
[root@haproxy /]# yum install haproxy
Dependencies Resolved
==========================================================================
Package Arch Version Repository Size
==========================================================================
Installing:
haproxy x86_64 1.5.18-1.el6 public_ol6_latest 799 k
Transaction Summary
==========================================================================
Install 1 Package(s)
Total download size: 799 k
Installed size: 2.5 M
Is this ok [y/N]: y
...
Installed:
haproxy.x86_64 0:1.5.18-1.el6
Complete!2. Configurar el frontend y el backend
La configuración vive en /etc/haproxy/haproxy.cfg:
[root@haproxy /]# cd /etc/haproxy
[root@haproxy haproxy]# ls
haproxy.cfgSe añaden las secciones frontend y backend:
#-----------------------------------
# Load Balance LDAP
#-----------------------------------
frontend f_oid 0.0.0.0:389
log global
mode tcp
option tcplog
option dontlognull
default_backend b_oid
backend b_oid
mode tcp
balance roundrobin
server oid1 ldap01.ejemplo.local:3060
server oid2 ldap02.ejemplo.local:3060Frontend es la configuración con la que HAProxy escucha las peticiones entrantes. Dos detalles importan aquí:
- El protocolo debe ser
tcp, porque la comunicación LDAP se hace sobre TCP y no sobre HTTP. - No puede faltar
default_backend: es el parámetro que enlaza con la sección donde están definidos los destinos.
El valor 0.0.0.0 indica que escuche en todas las interfaces que el servidor tenga configuradas y activas.
Backend es donde se referencian los dos equipos que tienen el servicio LDAP. También aquí es imprescindible declarar el modo tcp.
3. Reiniciar y validar los nodos
[root@haproxy ~]# service haproxy restart
Stopping haproxy: [ OK ]
Starting haproxy: [ OK ]Antes de probar el balanceador conviene comprobar que cada nodo responde por su cuenta. La prueba se hace desde un equipo distinto al de HAProxy y al de los LDAP:
[oracle@cliente ~]$ ldapbind -h ldap01.ejemplo.local -p 3060 -W cn=orcladmin
bind successful
[oracle@cliente ~]$ ldapbind -h ldap02.ejemplo.local -p 3060 -W cn=orcladmin
bind successfulCon los dos nodos validados, se prueba ahora contra el puerto 389 del balanceador:
[oracle@cliente ~]$ ldapbind -h haproxy.ejemplo.local -p 389 -W cn=orcladmin
bind successfulEl servicio de HAProxy está funcionando. Queda lo importante: validar que la alta disponibilidad hace su trabajo.
4. Probar la alta disponibilidad
El escenario de control es apagar los dos nodos LDAP y comprobar que el balanceador, efectivamente, ya no tiene a quién enviar la petición:
[oracle@ldap01 ~]$ opmnctl stopproc ias-component=oid1
opmnctl stopproc: stopping opmn managed processes...
[oracle@ldap01 ~]$ opmnctl status
Processes in Instance: asinst_1
------------------+--------------------+---------+---------
ias-component | process-type | pid | status
------------------+--------------------+---------+---------
ohs1 | OHS | 1636 | Alive
oid1 | oidldapd | N/A | Down
oid1 | oidldapd | N/A | Down
oid1 | oidmon | N/A | Down
EMAGENT | EMAGENT | 1635 | AliveLo mismo en el segundo nodo con ias-component=oid2. Con ambos abajo, la petición a través de HAProxy falla, como cabe esperar:
[oracle@cliente ~]$ ldapbind -h haproxy.ejemplo.local -p 389 -W cn=orcladmin
ldap_bind: Can't contact LDAP serverAhora se levanta solo uno de los dos nodos:
[oracle@ldap01 ~]$ opmnctl startproc ias-component=oid1
opmnctl startproc: starting opmn managed processes...
[oracle@ldap01 ~]$ opmnctl status
Processes in Instance: asinst_1
------------------+--------------------+---------+---------
ias-component | process-type | pid | status
------------------+--------------------+---------+---------
ohs1 | OHS | 1636 | Alive
oid1 | oidldapd | 3753 | Alive
oid1 | oidldapd | 3751 | Alive
oid1 | oidmon | 3745 | Alive
EMAGENT | EMAGENT | 1635 | AliveY la misma petición contra el balanceador vuelve a resolverse, aunque el otro nodo siga caído:
[oracle@cliente ~]$ ldapbind -h haproxy.ejemplo.local -p 389 -W cn=orcladmin
bind successfulLa prueba es simétrica: levantando oid2 y dejando oid1 abajo, el resultado es el mismo. Eso es exactamente lo que se busca — que la caída de un nodo no llegue al cliente.
Resultado
Con esta configuración, los clientes LDAP apuntan a un único destino —el puerto 389 del equipo HAProxy— y dejan de depender de qué nodo concreto esté vivo. El reparto se hace por round robin y la caída de cualquiera de los dos servidores es transparente para el usuario final.
Conviene tener presente que, tal como queda, el balanceador es ahora el punto único de fallo: el servicio LDAP tolera perder un nodo, pero no que se caiga HAProxy. En entornos donde eso importe, el siguiente paso es duplicar también el balanceador con una IP virtual entre las dos instancias.