NOTA: Describimos aquí la configuración que mejor nos ha parecido teniendo en cuenta una serie de factores: - Fiabilidad - Sencillez de administración - No excesiva complejidad interna (menos probablidad de fallos, más rápida la solución de prosibles problemas, etc.)
Antes de este modelo probamos muchos más, incluso mantener las configuraciones de réplicas como parte del DIT de los maestros para que sólo hubiera que tocar cosas en un sitio. En algunos casos llegamos a tener hasta 6 u 8 replicaciones configuradas, alguna dentro del mismo servidor contra él mismo. Y la verdad es que los mecanismos de replicación siempre han funcionado bastante bien.
Teníamos versiones muy antiguas (2.2.24 con LDBM) que no actualizábamos porque apenas daban problemas. Existía un servidor maestro y varias réplicas. El maestro no se usaba para búsquedas, sólo para modificaciones del DIT (con valores concretos y controlados de DNs y direcciones IP de origen) y para propagar los cambios a las réplicas, usando SLURP. Las réplicas a su vez no permitían modificaciones mediante updateref. Para no tener el servicio disperso por muchos ordenadores, el maestro compartía máquina con una de las réplicas, escuchando ambas en puertos IP distintos. El motivo de este diseño es principalmente la seguridad:
El balanceo de carga entre los réplicas era por round-robin DNS, per al final en unas máquinas se configuraba uno de los réplicas delante de otro segú si alguno estaba dando problemas, etc. En fin que el reparto de carga no era muy bueno.
En resumen, no estábamos tranquilos con versiones tan antiguas. Según parece OpenLDAP va a dejar de dar soporte a la configuración mediante el ficheros slapd.conf y permitirá únicamente la llamada 'cn=config', con toda ella dentro del propio directorio, que permite modificaciones en caliente, etc. Si en un momento dado tuviéramos prisa por actualizar la versión, nos encontaríamos con que llevaría su tiempo conocer el nuevo sistema.
Aparte, usarmos ya BDB que se supone que es mucho más eficiente, y también queremos configurar el master en activo-activo, ya que aunque antes no se modificaba a menudo el directorio y un fallo temporal en caso de problemas no era importante, ahora tenemos un sistema de gestión de cuentas muy potente, y los usuarios pueden estar en cualquier momento creando cuentas, o alias o cambiando sus claves.
Veíamos varios inconvenientes o posibles problemas potenciales en las nuevas versiones:
Dos servidores, cada uno corre una instancia de slapd, configurados en multimaster. Se replican entre ellos tanto el DIT como su propia configuración. Las modificaciones se pueden hacer en cualquiera de ellos. Cada uno escucha en dos puertos TCP distintos. Las reglas de control de acceso de slapd impiden cualquier posible modificación o acceso a información 'sensible' (userpassword, etc.) si la conexión viene por el puerto estandar. En iptables controlamos desde qué IPs se pueden abrir conexiones al puerto que sí tiene permisos (sólo algunos de nuestros equipos) El acceso a ellos por LDAP se hace a través de un balanceador (CISCO 6500 con SLB), que hace reparto de carga + failover.
Lo primero es crear un fichero slapd.conf con la configuración más afinada posible, porque una vez que lo pasemos a cn=config ya no será tan fácil hacer modificaciones (al menos hasta que tengamos un poco de práctica). Se arranca el servidor y se comprueba que todo funciona más o menos bien. Luego tiramos el servidor y convertimos de slapd.conf a cn=config con:
# slaptest -f /etc/openldap/slapd.conf /etc/openldap/slapd.d
(Usaré comandos y pathnames de CentOS)
Una vez arrancado, dará errores de sincronización porque aún no hemos arrancado el segundo servidor.
Hacemos exactamente lo mismo en el otro servidor y lo arrancamos. Entre ellos se sincronizarán, tras unos minutos en los que veremos que se consume bastante CPU. Si tenemos el DIT vacío, lo único que se sincroniza ahora son las configuraciones. Si tenemos ya datos (ver la sección Momento del paso a producción) sincronizarán todo el DIT.
La configuración multimaster se consigue con las dos sentencias syncrepl y la opción mirrormode.
La configuración ahora está en la rama cn=config del directorio. Las operaciones deben realizarse mediante el protocolo LDAP. En último caso se puede tocar a mano siguiendo este procedimiento:
Para las operaciones sobre LDAP, ver el documento compañero a éste. Lo separo porque el otro nos servirá con frecuencia de chuletero.
Una vez que tenemos montados ambos servidores en multimaster y hemos probado que tod va bien, llegó el momento...
En ningún momento se va a estar sin poder realizarse consultas LDAP. Lo que vamos a hacer, a grandes rasgos, es:
Antes que nada, en los nuevos servidores, en iptables cortamos el acceso al puerto TCP donde se permiten modificaciones, para que nos de tiempo a probar cosillas antes de que se modifique nada de los datos.
Desde el anterior servidor maestro, ejecutamos el siguiente script, que necesita pocas explicaciones:
#!/bin/sh
L1=<nuevo-servidor-ldap-1>
L2=<nuevo-servidor-ldap-2>
service ucoldapm stop # ucoldapm es el master, el único que admite moficiaciones
/usr/local/openldapm/sbin/slapcat > /var/tmp/ldp.sal
ssh $L1 /etc/init.d/slapd stop
ssh $L2 /etc/init.d/slapd stop
scp /var/tmp/ldp.sal $L1:/var/tmp
ssh $L1 rm -rf /var/lib/ldap/*
ssh $L2 rm -rf /var/lib/ldap/*
# usamos '-q' porque ya se han hecho pruebas antes y no es necesario
# De lo contrario sería mucho más lento
ssh $L1 slapadd -q -F /etc/openldap/slapd.d -l /var/tmp/ldp.sal
ssh $L1 chown -R ldap:ldap /var/lib/ldap
ssh $L1 rsync -a /var/lib/ldap $L2:/var/lib/
ssh $L1 cp /dev/null /var/log/ldap
ssh $L2 cp /dev/null /var/log/ldap
ssh $L1 /etc/init.d/slapd start
ssh $L2 /etc/init.d/slapd start
Ahora durante unos 5-10 minutos sube mucho la CPU de los servidores, se están sincronizando con un árbol nuevo para ellos. En cuanto baja la carga, hacemos los cambios en DNS.
En poco tiempo, a medida que se pillan los cambios del DNS, entra toda la carga de consultas a los nuevos. Las modificaciones igualmente van a los nuevos.
Este procedimiento funciona por que en todos los sitios están configurados los nombres de host de los servidores LDAP, no sus IPs (bueno, algún sitio había...). Si no es así habrá que cambiar el procedimiento.
Para ver si hay sitios que acceden por IP o casos raros, conviene seguir mirando los logs de los servidores antiguos. Para el master, antes de arrancarlo de nuevo tras el paso, quitarle todas las reglas que permitían escrituras/modificaciones y arrancarlo. Observar en el log si hay intentos de acceso. Como algunas aplicaciones de LDAP mantienen conexiones abiertas de forma permanente, conviene reiniciar los servidores esclavos antiguos. De esa forma volverán a abrir la conexión, ahora a los servidores nuevos.
Aquí puede haber problemas: Si se permite en seguida las modificaciones en el nuevo par de servidores maestros y aún hay clientes usando los servidores antiguos, estos no verán los cambios. En nuestro caso estuvimos algunas horas hasta que conseguimos que TODOS los clientes usaran los servidores nuevos. Hasta qué punto es importante este efecto es algo que tienen que valorar en cada sitio.
Si se usa una configuración multimaster con OpenLDAP 2.4, todos los réplicas deben tener versiones también 2.4