Todos los que hemos usado OpenLDAP desde hace tiempo como software para desplegar nuestros servicios de directorio, hemos venido sufriendo el problema de las réplicas en los esclavos para mantener la alta disponibilidad. La solución con la que contábamos era el uso de SLURPD, un pequeño demonio que se ejecutaba en el servidor con el LDAP maestro. Cada operación que se realizaba en el directorio se anotaba en un fichero de texto plano junto a la hora, y el demonio iba aplicando los cambios del fichero en cada una de las réplicas. Este proceso era bastante inestable, porque asumía siempre que la replica estaba en un estado determinado, y a partir de él aplicaba cambios. Esto no siempre era así, porque podíamos haber parado la réplica o haberla recuperado de un backup, y al final teníamos que nunca estábamos completamente seguros del estado de nuestras réplicas hasta que parábamos todo el directorio, y copiábamos a mano la base de datos del maestro en cada una de las réplicas. Teníamos demasiadas paradas en un servicio siempre importante, y el proceso SLAPD solía estar siempre en la cima del top comiendo toda la CPU que podía, sin contar las veces que el demonio SLURPD moría por causas desconocidas.
Por suerte con la versión 2.3 de OpenLDAP aparece un nuevo mecanismo de sincronización del directorio basado en un overlay y llamado SyncRepl. Este mecanismo lo que hace es escribir en cada modificación un timestamp con la hora a la que se realizó y se guarda en la propia base de datos dentro de los atributos del objeto modificado, y además mantiene un timestamp global que contiene el valor para la última modificación. Las réplicas ahora, no esperan a que el maestro les envíe las modificaciones sino, que se conectan contínuamente al maestro y le preguntan por el valor globlal: Lo comparan con el que ellas tienen anotado y solicitan todos los objetos comprendidos entres estos dos timestamp para modificarlos en la base de datos local. Este mecanismo en mucho más robusto, y aporta tranquilidad a la vida de los administradores de OpenLDAP.
Para configurarlo tendremos que:
- Editar la configuración del maestro y añadir la configuración de SyncRepl a justo después de la definición de nuestro backend
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
lastmod on - Editar la configuración del esclavo y añadir la configuración de SyncRepl a justo después de la definición de nuestro backend, como hicimos para el maestro, y además añadir al final cómo conectar con el LDAP que hace de maestro:
# Configurar el proveedor... (nuestro master)
syncrepl rid=001
provider=ldap://__IP_MAESTRO_LDAP__:389
type=refreshAndPersist
retry="60 +"
searchbase="dc=DOMINIO"
filter="(objectClass=*)"
scope=sub
attrs="*,+"
schemachecking=off
bindmethod=simple
binddn="cn=admin,dc=DOMINIO"
credentials=CLAVE_DEL_ADMIN
updateref ldap://__IP_MAESTRO_LDAP__:389 - Añadir índices para los campos entryCSN y entryUUID, en la sección de índices del fichero de configuración de los LDAPs. Estos campos es donde SyncRepl va anotando las modificaciones.
index entryCSN,entryUUID eq
Después de aplicar estos cambios, tendremos que reconstruir la base de datos del maestro, con el fin de que se creen todos los objetos con estos campos reservados. Luego regenerar los índices de la base de datos con
slapindex, y copiarla a los nodos esclavos para que arranquen en un estado sincronizado.La foto la he sacado del album de Michael Dawes en flickr
2 comentarios:
hola amigo, una consulta, solo eso tendría que hacer?? es decir, agregando esas líneas en el server maestro y esclavo respectivamente soluciono la replicación?? y cuando dices montar todo de nuevo te refieres a poblar el ldap maestro con smbldap-populate para que también se replique en el esclavo??
saludos
hola :),
Si, con esto es suficiente.
Cuando digo montar todo de nuevo, me refiero a la Base de datos de LDAP:
1) Parar los esclavos.
service ldap stop
2) Exportar toda la BBDD con slapcat a un fichero en el maestro. Te generará un ldif con todo el directorio, y quizás debas eliminar algunas líneas:
slapcat -l /tmp/ldif1
grep -v entryUUID /tmp/ldif1 \
| grep -v creatorsName \
| grep -v modifiersName \
| grep -v createTimestamp \
| grep -v modifyTimestamp \
| grep -v entryCSN \
| grep -v 'structuralObjectClass:' \
> /tmp/ldif2
3) Parar el servicio en el maestro, y borrar la BBDD:
service ldap stop
cp /var/lib/ldap/DB_CONFIG /tmp
rm /var/lib/ldap/* -fr
cp /tmp/DB_CONFIG /var/lib/ldap/
4) Arrancar el servicio en el maestro e importar el Backup. Esto se hace para que ahora todos los objetos tenga los campos entryCSN y entryUUID:
service ldap start
ldapadd -x -h localhost \
-D "cn=admin,DOMINIO" -W \
-f /tmp/ldif2
5) Parar el servicio en el maestro y copiar la BBDD a los esclavos:
service ldap stop
tar cvfp - /var/lib/ldap \
| ssh root@ESCLAVO "cd / && tar xvfp -"
6) Iniciar el servicio en el maestro y en todos los esclavos. Probar a cambiar alguna entrada y comprobar.
- Recuerda que en los esclavos también debes añadir los índices para entryCSN y entryUUID.
- Si ya tenías hecho el smbldap-populate, no necesitas volver hacerlo.
Publicar un comentario