O Active Directory é uma aplicação muito robusta, como deveria ser para um elemento tão fundamental da infra-estrutura de TI de uma empresa. Mas a arquitectura que o torna robusto também o torna difícil de compreender. Esta falta de compreensão leva muitas vezes a suposições na sua estratégia de recuperação que podem deixar o seu AD avariado sem uma forma de voltar ao normal.
Quando a equipa de engenharia e operações do AD elabora o seu plano de recuperação, a tendência natural é pensar primeiro na recuperação dos controladores de domínio (DCs). Este é um bom primeiro passo, que se baseia em duas razões muito práticas. Em primeiro lugar, os DCs têm sido, historicamente, o componente do AD que mais falha. Em segundo lugar, a recuperação e reconstrução de servidores é uma das tarefas operacionais mais antigas do manual de execução de operações, pelo que é natural que a aplique a esta situação.
Mas no caso do Active Directory, a equipa muitas vezes não continua e não planeia o outro tipo de desastre que o Active Directory pode encontrar: corrupção lógica dos dados do AD.
A teia da replicação
Parte do que torna o Active Directory difícil de entender e solucionar problemas operacionais é a complexidade do seu modelo de dados lógicos. Sempre olhei para o AD através do que considero ser vários pares de óculos. O primeiro e mais óbvio é a rede de DCs físicos e sua integridade. Temos tendência a pensar nos DCs de uma floresta porque são os activos tangíveis do Active Directory. Em seguida, temos os meus óculos Sites. Com estes óculos, vejo a topologia dos sites da rede empresarial e a forma como os dados são constantemente replicados entre os DCs: sites com boa conectividade (que podem ou não ter um DC), ligações de sites para ligar os sites da forma mais adequada às necessidades dos utilizadores e das aplicações que utilizam os sites do AD, e afinação destas ligações de sites com o custo das ligações e a prioridade do DNS para favorecer alguns DCs em detrimento de outros.
Mas a realidade é mais complicada do que um diagrama de arquitectura de um site. Se analisarmos de perto a replicação com uma ferramenta como o ADREPLSTATUS ou o Repadmin, a verdadeira complexidade do Active Directory é revelada. Cada CD aloja várias partições de directório que contêm dados importantes, e as diferentes concepções de floresta influenciam as partições que um CD aloja. Cada uma dessas partições está ligada a vários outros DCs noutros locais do domínio ou da floresta. Vejo isto como uma meada de centenas de pedaços de fio multicolorido que ligam cavilhas num quadro de cavilhas. Algumas cores de fio vão para apenas alguns pinos, enquanto outras cores vão para todos os pinos do quadro. É uma maravilha que funcione de todo, quanto mais que funcione tão bem.
Mas esse mecanismo funciona tão bem para dados ruins quanto para dados bons. Em caso de corrupção de dados lógicos, os dados corrompidos serão replicados através de todos os DCs no domínio ou floresta. Nos casos em que a corrupção lógica é grave (como a desactivação da conta do DC no AD através da consola normal de Utilizadores e Computadores), é necessário efectuar uma recuperação de desastre do AD. O processo de restauro da Microsoft inclui mais de 50 passos manuais, o que o torna lento, propenso a erros e insuficiente para os requisitos da empresa. A complexidade do procedimento é suficientemente elevada para que a Microsoft o ofereça como parte do ADRES (AD Recovery Execution Service), um serviço de 5 dias que se concentra em questões de recuperação do AD.
Muitas empresas implementaram sites de recuperação de desastres no Active Directory para fornecer DCs de failover para utilizadores e serviços se o DC normal tiver falhado. No entanto, os sites de recuperação de desastres ou o número de DCs que tiver não o ajudarão em caso de corrupção lógica - na verdade, tornarão a recuperação mais complicada.
É aí que pode ter um procedimento manual a seguir ou uma solução automatizada que o fará por si.
