Active Directory es una aplicación muy robusta, tal y como debe ser un componente tan fundamental de la infraestructura informática de una empresa. Sin embargo, la arquitectura que le confiere esa robustez también hace que resulte difícil de comprender. Esta falta de comprensión suele dar lugar a suposiciones en la estrategia de recuperación que pueden dejar el AD inoperativo, sin posibilidad de volver a la normalidad.
Cuando el equipo de ingeniería y operaciones de AD elabora su plan de recuperación, la tendencia natural es pensar primero en recuperar los controladores de dominio (DC). Este es un buen primer paso, y se basa en dos razones muy prácticas. En primer lugar, los DC han sido históricamente el componente de AD que más fallos ha sufrido. En segundo lugar, la recuperación y reconstrucción de servidores es una de las tareas operativas más antiguas del manual de operaciones, por lo que es natural aplicarla a esta situación.
Sin embargo, en el caso de Active Directory, el equipo a menudo no va más allá ni tiene en cuenta otro tipo de incidente que puede afectar a Active Directory: la corrupción lógica de los datos de AD.
La red de réplicas
Parte de lo que hace que Active Directory resulte difícil de entender y de solucionar problemas operativos es la complejidad de su modelo lógico de datos. Siempre he analizado AD a través de lo que yo considero varios «pares de gafas». El primero y más obvio es la red de servidores de dominio (DC) físicos y su estado. Solemos pensar en los servidores de dominio de un bosque porque son los activos tangibles de Active Directory. A continuación están mis «gafas de sitios». Con ellas, observo la topología de sitios de la red corporativa y cómo se replican constantemente los datos entre los servidores de dominio: sitios con buena conectividad (que pueden tener o no un servidor de dominio en su interior), enlaces de sitio para conectar los sitios de la forma que mejor se adapte a las necesidades de los usuarios y las aplicaciones que utilizan los sitios de AD, y el ajuste fino de estos enlaces de sitio mediante el cálculo de costes de enlace y la prioridad DNS para dar preferencia a unos servidores de dominio sobre otros.
Pero la realidad es más complicada que un diagrama de arquitectura del sitio. Si se analiza detenidamente la replicación con una herramienta como ADREPLSTATUS o Repadmin, se pone de manifiesto la verdadera complejidad de Active Directory. Cada controlador de dominio (DC) aloja varias particiones de directorio que contienen datos importantes, y los diferentes diseños de bosque influyen en las particiones que aloja cada DC. Cada una de esas particiones se conecta con varios otros servidores de dominio situados en otras partes del dominio o del bosque. Yo lo veo como una madeja de cientos de hilos multicolores que conectan las clavijas de un tablero perforado. Algunos colores de hilo van a solo unas pocas clavijas, mientras que otros colores van a todas las clavijas del tablero. Es una maravilla que funcione, por no hablar de que lo haga tan bien.
Pero este mecanismo funciona tan bien para datos malos como para datos buenos. En caso de corrupción de datos lógicos, los datos corruptos se replicarán a través de todos los DC del dominio o bosque. En los casos en que la corrupción lógica es grave (como la desactivación de la cuenta del DC en AD a través de la consola estándar de Usuarios y Computación) es necesario llevar a cabo una recuperación de desastres de AD. El proceso de restauración de Microsoft incluye más de 50 pasos manuales, lo que lo hace lento, propenso a errores e insuficiente para los requisitos de la empresa. La complejidad del procedimiento es lo suficientemente alta como para que Microsoft lo ofrezca como parte de ADRES (AD Recovery Execution Service), un compromiso de servicio de 5 días que se centra en problemas de recuperación de AD.
Muchas empresas han implementado sitios de recuperación ante desastres en Active Directory para proporcionar DC de conmutación por error para los usuarios y el servicio si el DC normal ha fallado. Sin embargo, los sitios de DR o el número de DC que tenga no le ayudarán en caso de corrupción lógica: en realidad, complicarán la recuperación.
Ahí es donde puede tener un procedimiento manual que seguir o una solución automatizada que lo haga por usted.
