Active Directory è un'applicazione molto robusta, come dovrebbe essere per un elemento così fondamentale dell'infrastruttura IT di un'azienda. Ma l'architettura che la rende robusta la rende anche difficile da capire. Questa mancanza di comprensione spesso porta a fare delle ipotesi nella strategia di ripristino che possono lasciare l'AD in panne senza un modo per tornare alla normalità.
Quando il team di ingegneria e operazioni AD elabora il piano di ripristino, la tendenza naturale è quella di pensare innanzitutto al ripristino dei controller di dominio (DC). Si tratta di un buon primo passo, che si basa su due ragioni molto pratiche. In primo luogo, i DC sono storicamente il componente AD che si guasta di più. In secondo luogo, il ripristino e la ricostruzione dei server è una delle attività operative più vecchie del libro delle operazioni, quindi è naturale applicarla a questa situazione.
Ma nel caso di Active Directory, il team spesso non considera e non pianifica l'altro tipo di disastro che Active Directory può incontrare: il danneggiamento logico dei dati AD.
La rete di repliche
Parte di ciò che rende Active Directory difficile da capire e da risolvere operativamente è la complessità del suo modello logico dei dati. Ho sempre guardato AD attraverso quello che considero un paio di occhiali. Il primo e più ovvio è la rete di DC fisici e il loro stato di salute. Si tende a pensare ai DC di una foresta perché sono le risorse tangibili di Active Directory. Poi ci sono gli occhiali per i siti. Con questi occhiali vedo la topologia dei siti della rete aziendale e il modo in cui i dati vengono costantemente replicati tra i DC: i siti con una buona connettività (che possono avere o meno un DC al loro interno), i collegamenti tra i siti per collegarli in modo da soddisfare al meglio le esigenze degli utenti e delle applicazioni che utilizzano i siti di AD, e la messa a punto di questi collegamenti tra i siti con il link costing e la priorità DNS per favorire alcuni DC rispetto ad altri.
Ma la realtà è più complicata di un diagramma di architettura del sito. Se si osserva da vicino la replica con uno strumento come ADREPLSTATUS o Repadmin, si scopre la vera complessità di Active Directory. Ogni DC ospita diverse partizioni di directory contenenti dati importanti e le diverse strutture delle foreste influenzano le partizioni ospitate da un DC. Ognuna di queste partizioni si collega a diversi altri DC nel dominio o nella foresta. Lo vedo come una matassa di centinaia di pezzi di filo multicolore che collegano i pioli di una lavagna. Alcuni colori di filo vanno a pochi pioli, mentre altri colori vanno a tutti i pioli della lavagna. È un miracolo che funzioni, per non parlare del fatto che funzioni così bene.
Ma questo meccanismo funziona altrettanto bene sia per i dati danneggiati che per quelli buoni. In caso di corruzione dei dati logici, i dati corrotti verranno replicati attraverso tutti i DC del dominio o della foresta. Nei casi in cui il danneggiamento logico è grave (come la disabilitazione dell'account del DC in AD attraverso la console standard Utenti e calcoli) è necessario eseguire un ripristino di emergenza di AD. Il processo di ripristino Microsoft comprende più di 50 passaggi manuali, che lo rendono lento, soggetto a errori e insufficiente per le esigenze aziendali. La complessità della procedura è tale da indurre Microsoft a offrirla come parte di ADRES (AD Recovery Execution Service), un servizio di 5 giorni che si concentra sui problemi di ripristino di AD.
Molte aziende hanno implementato siti di disaster recovery in Active Directory per fornire DC di failover agli utenti e ai servizi in caso di guasto del DC normale. Tuttavia, i siti di DR o il numero di DC che avete non vi aiuteranno in caso di corruzione logica, anzi renderanno il recupero più complicato.
A questo punto si può scegliere tra una procedura manuale da seguire o una soluzione automatizzata che lo faccia per voi.
