Inicio > General, Lecturas > Replicación en OpenLdap 2.3.x

Replicación en OpenLdap 2.3.x

A veces es necesario disponer de varias copias idénticas de nuestro servidor LDAP:

  • Cuando el tráfico sea muy alto, para dividir las consultas
  • Dotar de alta disponibilidad al directorio
  • En el caso de que los clientes estén dispersos geográficamente.

¡La replicación es la solución!

Replicación es el proceso de configuración de un directorio para que mantenga múltiples copias de sus datos en otros árboles sincronizadas en el tiempo. En LDAP, la replicación es un modelo jerárquico, un servidor se considera el maestro, o proveedor, este servidor es el encargado de mantener la última versión de la información del directorio. Bajo el servidor maestro se encuentra uno o más servidores en la sombra (esclavos, replicas o consumidores), un esclavo mantiene una réplica del árbol del servidor maestro y los clientes pueden realizar las consultas sobre uno de los esclavos.. (Los esclavos son de sólo lectura).

Necesitamos tener directorios de respaldo, está claro, en la versión 2.3 de Openldap (La que vamos a usar) todavía no tenemos sincronización multi-master, pero no todo van a ser malas noticias, abandonamos slurpd y vamos a usar syncrelp la nueva forma de sincronizar directorios Openldap.

Lo primero que vamos a hacer es configurar un servidor como maestro. Este servidor escucha peticiones de sincronización de los esclavos y les envía las actualizaciones solicitadas. No es objeto de este manual la configuración SLAPD, asi que supondremos que tiene su directorio perfectamente configurado y ahora vamos a convertirlo en maestro. La funcionalidad de maestro está implementada en el “overlay” syncprov (proveedor de sincronización). Lo primero es cargar el modulo y configurarlo.

En el caso de que nuestro OpenLdap esté configurado por módulos deberiamos de cargarlo.
moduleload syncprov
Por defecto en Red Hat ya viene cargado ese módulo, OpenLdap está compilado de forma monolítica. (Omitimos esa instrucción)
Configuramos nuevos índices que necesitamos en la nueva bbdd preparada para synrepl.

index entryCSN,entryUUID eq

El siguiente paso es cargar y configurar el overlay syncprov. Sólo existen dos directivas de configuración para este overlay, por lo que nuestra configuración quedaría de la siguiente manera:

overlay syncprov
syncprov-checkpoint 50 10
syncprov-sessionlog 100

La primera línea carga el overlay syncprov. La siguiente línea especifica con que frecuencia Syncrepl escribe información en la bbdd y la creación de log.
La mayor parte del trabajo se realiza en el esclavo, bajo la directiva syncrepl

syncrepl rid=001
provider=ldap://directory.e
xample.com
type=refreshOnly
interval=00:00:05:00
searchbase=”dc=example,dc=com”
binddn=”uid=syncrepl,ou=system,dc=example,dc=com”
credentials=secret

En el ejemplo tenemos la minima configuración necesaria para hacer que syncrepl funcione. La directiva tiene 7 parámetros del tip atributos=valor; rid, provider, type, interval, searchbase, binddn, y credentials
El primer parámetro es rid (Replica Identifier), este número de tres dígitos identifica de manera unica a cada uno de los esclavos que atacan un mismo proveedor ( master). La instacia master de SLAPD utiliza el RID del “consumidor” (esclavo) para realizar un seguimiento de lo sservidores que están en contacto con él. Normalmente es mejor empezar con un número bajo de RID y aumentarlo con cada nuevo servidor esclavo. rid=001 será el primer esclavo, si añadiéramos un segundo esclavo sería rid=002

El parámetro provider contiene la url LDAP para el maestro. Cualquier protocolo ldap://host o ldaps://host se puede usar. El host puede ser un nombre de host o una dirección IP el puerto es opccional se puede agregar al final separado por dos puntos, por ejemplo en el caso de usar ldaps e un puerto extraños LDAPS: / / 10.0.1.34:6868. Tenga en cuenta que no se pueden usar url’s de ldap complejas con base’s filtros etc…

El parámetro type determina cual de los modos de replicación utilizará el servidor consumidor (esclavo) para conectar con el proveedor ( maestro). Los únicos valores válidos son refreshOnly (Modo Polling) y refreshAndPersist ( Modo )Push

En nuestro ejemplo hemos utilizado la opción refreshOnly, si utilizamos refreshAndPersist el parámetro intervalo será ignorado. No hay diferencias significativas entre una configuración y otra, si usamos refreshOnly los cambios se replicaran al servidor esclavo en los intervalos de refresco, si usamos refreshAndPersist se transmitiran los cambios inmediatamente después de hacerse en el maestro al esclavo
El parámetro intervalo indica el tiempo que tardará el servidor esclavo antes de verificar si hay cambios en el maestro para actualizarse, En el caso refreshOnly el esclavo conectará al servidor verificará si hay actualizaciones y se desconecta, esperará el tiempo fijado en intervalo para comprobar de nuevo
La sintaxis del parámetro intervalo es: dd:hh:mm:ss, en nuestro caso se refresca cada 5 minutos.
Uno de los problemas del modo refreshOnly es que cuando toque consultar al master para sincronizar no este disponible, por ejemplo por un fallo en el servidor o demasiada carga en lar red. ¿Qué hará el esclavo? Podemos añadir una línea de este tipo: retry=”120 10″, con esta línea el esclavo reintentará la conexión cada 120 segundos 10 veces mientras no este el master disponible

La directiva searchbase es una de las directivas para construir desde donde vamos a sincronizar, en este ejemplo el searchbase coincide con el RootDN, por lo que vamos a sincronizar todo el arbol. El resto de atributos para “complicar” la busqueda son scope, filter, attrs, attrsonly, sizelimit, and timelimit.
Por defecto el atributo scope es igual a sub (la busqueda es en profundidad), el valor del filtro es filter=(objectclass=*)
y el attrs=”*,+”, ser recuperan todos los objetos y todos los atributos. Los parametros sizelimit y timelimit tienen como valor por defecto “ilimitado”.
Los últimos parámetros (seis y siete) de la directiva synrepl son binddn y credentials el usuario y el password con el que nos vamos a conectar al SLAPD master. Es obvio que uid=syncrepl tiene que estar creado en el maestro. Los permisos de lectura/escritura sobre el árbol del usuario synrepl deben estar en las ACL’s del master.

  1. samorrac
    mayo 30, 2009 a las 4:44 pm

    Gracias. Buen artículo.

  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: