Quando um administrador realiza alterações em um domain controller, o servidor precisa atualizar a sua base do AD com os outros DCs da rede. Essa operação precisa ser transparente não podendo gerar conflitos nem perder informações. A esse processo chamamos de replicação.
A replicação ocorre sempre que um objeto é adicionado ao Active Directory, quando um objeto tem os valores de seus atributos alterados, o nome de um container de objeto alterado ou quando um objeto é excluído.
Quando uma alteração ocorre, o domain controller alterado gera um pacote chamado Change Notification que é um aviso aos outros DCs do seu site. Esse aviso é gerado quando ocorrerem alterações na base de dados e são enviados a cada 15 segundos. Quando um DC recebe o comando de change notification, ele gera um pedido de Request Change ao DC que lhe enviou o comando e esse pacote é uma solicitação do valor da alteração. Ao receber esse pacote, o DC originário da atualização manda um pacote Update que é o comando com as atualizações da base do AD. Se ocorrer o acúmulo de pedidos request change recebidos e pendentes em um DC, ele coloca as solicitações em queue (espera) até conseguir responder a todas, uma a uma.
A cada 15 segundos os DCs criam um pacote change notification e enviam aos outros DCs do site. Esse procedimento é realizado mesmo sem atualizações realizadas na base. Esse processo é chamado de Replication latency e serve para sempre manter as bases dos servidores atualizadas. Essa completa atualização entre todos domain controllers da rede ganha o nome de convergência.
Mas existem alterações na base que não respeitam o limite de 15 segundos para enviar o comando change notification. Essas atualizações são chamadas Urgent Replication e são enviadas sem delay. Esse tipo de atualização é compreendido por atributos sensíveis ou de segurança como travamentos de contas, alterações de senhas e outras configurações importantes.
Em redes com vários domain controllers, poderia ocorrer o risco de haver replicação desnecessária. Para evitar esse problema, cada DC adiciona um USN (Update Sequence Number) para cada alteração em um atributo. Esse número também serve para manter a integridade da alteração. As atualizações também contam com o Globally Unique Stamp que são informações de número de versão, marcas de tempo (timestamp) e GUID (server globally unique identifier) do servidor de origem que são adicionadas as atualizações.
Essas informações são adicionadas às atualizações para evitar conflitos entre pacotes. Os conflitos ocorrem quando dois DCs possuem atualizações nos mesmos objetos. O Active Directory resolve três tipos de conflitos: atributos dos objetos, objetos excluídos e nomes iguais de objetos (RDN – Relative Distinguished Name). Quanto ocorre um conflito de alterações de atributo, a alteração mais antiga acaba alterada para a atualização mais nova. No caso de conflitos de exclusão de objetos, o item alterado é tirado da base do AD e colocado na unidade organizacional Lost and Found, ficando inutilizável mas ficando o acesso permitido para que o administrador possa voltar o objeto ao seu local de origem. Conflitos RDN são resolvidos fazendo o update gerando pelo DC de maior GUID ser mantido e o outro update tenha o seu nome alterado.
A replicação entre domain controllers possui diferenças de funcionalidades dependendo do nível de funcionalidade da floresta. Quando a floresta trabalha em modo misto ou em modo 2000, os DCs passam informação de todos os atributos do objeto ao realizar uma atualização da base. Caso a atualização contenha informações sobre vários objetos, todos os atributos dos objetos alterados serão passados na replicação. Em modo 2003 a replicação é realizada somente com os atributos alterados e não todas informações do objeto. Esse processo visa diminuir o tráfego de rede utilizado e melhorar a velocidade da rede para a convergência da base do AD.
A base do Active Directory é dividida em partições e cada uma tem suas funções específicas, segue abaixo uma descrição delas:
– Schema: essa partição contém definição de todos objetos e atributos que você pode criar no diretório e as regras para criá-los e manipulá-los. Todos DCs da floresta possuem a partição de schema.
– Configuração: contém informações sobre a estrutura do AD incluindo quais domínios, sites, domain controllers e cada serviço existe na floresta. Todos os domains controllers da floresta possuem essa partição.
– Domínio: a partição de domínio é guardada em cada DC do domínio, podendo assim existir várias partições de domínio na mesma floresta. Essa partição contém dados de todos objetos e informações do domínio como usuários, grupos, computadores e unidades organizacionais. Todas informações dessa partição é guardada no global catalog com somente o cabeçalho da informação.
– Aplicação: possui informação de aplicações que se adicionam ao AD. Exemplos dessa partição estão o Exchange, SQL Server entre outros. Essas informações não são acrescidas ao GC.
A replicação do domínio e da floresta é feita de modo separado. Quando se fala somente de um domínio, a replicação é realizada entre todos os servidores do domínio com todas as partições da base do Active Directory, como ilustra a imagem abaixo:
No caso de uma floresta, a partição de Schema e Configuração é replicada para todos os Domain Controllers da floresta, mas a informação das outras partições, somente são replicadas entre os DC´s do domínio. Com isso se forma duas correntes de atualizações dentro da mesma rede, ficando como a figura abaixo:
O Global Catalog possui uma replicação parecida com a replicação da partição de Schema, é replicada para cada servidor DC que possua o papel de Global Catalog Server na floresta, criando assim uma terceira rede de replicação, como mostra a figura abaixo:
Com isso concluímos toda a cadeia de replicação que pode ocorrer dentro de uma mesma rede. Abaixo iremos explicar como funciona o KCC, ferramenta que cria a topologia dentro dessa rede de replicação.
KCC
A topologia de replicação é a rota através da qual os DCs se replicam na floresta. Um domain controller sempre se atualiza com mais dois DCs, essa atualização se faz com todos os servidores até se criar um círculo de atualizações no domínio.
A geração dessa topologia é criada pelo KCC (Knowloedge Consistency Checker) que faz automaticamente a avaliação dos servidores DCs da rede e informa escolhe qual irá trocar informações com quem. O KCC roda em todos DCs do domínio e a cada 15 segundos checa se os parceiros do servidor estão ativos. Caso esse teste falhe, o programa pede um recalculo de topologia. A informação utilizada pelo KCC é o custo de transmissão de dados, o link entre os parceiros e os protocolos utilizados.
O KCC cria uma rede de atualizações em anel na rede em que se possuem no máximo 7 máquinas domain controllers, acima desse número, o KCC cria uma estrutura que interliga todos os servidores. Essa alteração de estrutura se deve ao Propagation dump que é um processo que mata a atualização após 3 saltos, evitando asism o update ao infinito. Abaixo uma imagem que ilustra a propagação das atualizações nos saltos de transferência de dados.
A função do KCC é de ler, criar e apagar informações na base do Active Directory. Para a maioria das aplicações, o KCC que roda em um DC não se comunica diretamente com outro DC para criar a topologia. Para isso todos KCCs utilizam o conhecimento comum dos dados globais guardados na partição de configuração do AD para a geração da topologia. Com essas informações os KCCs se utilizam de um algoritmo para convergir a rede em uma mesma visualização da topologia de replicação.
Cada KCC usa a informação em memória da base para criar conexões que aplicam a si mesmos. Um KCC se comunica direto com outro KCC somente para trocar informações de erros e essa comunicação é feita somente por RPC (Remote Procedure Call) em conexões IP. O KCC usa a informação de erro para identificar falhas na topologia de replicação. Essa solicitação acontece somente entre domain controllers do mesmo site.
A figura abaixo mostra como é realizada a criação da estrutura de replicação. O KCC armazena na base dados de configuração global os objetos de conexão que ele pode se utilizar. Já o ISTG, explicado mais abaixo, cria a estrutura de replicação entre sites.
Em cada site um domian controller é escolhido para trabalhar como Intersite Topology Generator (ISTG). Para permitir a replicação entre sites, o ISTG designa um ou mais servidores para realizarem a replicação site-a-site. Esses servidores são chamados de Bridgehead servers. Então o ISTG cria a topologia entre os sites com os objetos de conexão e escolhe qual servidor irá trabalhar com essa conexão.
Na replicação entre sites, é utilizado o Inter-site Trasnports. Nesse campo é realizada a configuração que permite ao administrador escolher qual site tem acesso ao outro, se existe um horário específico para a replicação de dados e qual o custo de cada conexão. A definição de custos é interessante para definir uma agenda de replicação indicando ao domínio a melhor forma de se comunicar entre os sites dependendo da estrutura da empresa.
Ferramentas de diagnóstico
Para se diagnosticar problemas de replicação, o Windows 2003 conta com algumas excelentes ferramentas de diagnóstico. Entre elas se destacam o Replication Monitor (repmon) que mostra graficamente a topologia de replicação de um site, o repadmin que é uma ferramenta em modo texto e a ferramenta mais conhecida para diagnósticos de domínio que é o DCDiag que realiza uma verificação de toda a estrutura do AD.
Todas essas ferramentas podem ser encontradas no sistema ou com a instalação do Support Tools do Windows 2003, ferramenta muito importante para o Administrador de sistemas Windows.
Ray Tomlinson criou o e-mail há 40 anos
Thiago Marques 