ADM de Redes

Um Blog sobre o dia a dia do Administrator de Redes e Servidores Microsoft

By

Virtualização de Domain Controllers – Parte 04

Olá Pessoal,

Mais uma parte de nossa série de posts sobre Domain Controllers Virtualizados, hoje abordando um cenário que pode causar muitos problemas. Trata-se da dependencia do Serviço de Cluster no Windows Server sobre o Active Directory.

A essa altura do campeonato, você já deve ter percebido que ter os Domain Controllers virtualizados não é impossível nem algo de outro mundo. Requer alguns cuidados a mais, sim, mas é plausível. Porém, há uma configuração de DC virtualizado que pode ser um problema. Este problema é quando você virtualiza todos os Domain Controllers em cima, não de um Host de Virtualização, mas de um Cluster.

Até o Windows Server 2008 R2, o serviço de cluster só irá iniciar se o contato com um Domain Controller for estabelecido. Se você colocar todos os seus Domain Controllers virtualizados em um Cluster, você terá problemas se por algum motivo como falta de energia, os hosts do seu cluster desligarem. Para resolver essa situação, temos duas alternativas:

A primeira é colocar o nó do cluster como Domain Controller, apenar de ser fortemente desencorajado, essa situação é relativamente comum, mesmo para quem não tem o DC virtualizado e não teria o problema acima, mas quer garantir que o acesso ao AD esteja sempre disponível. Essa solução não é mais suportada no Windows Server 2012, e já explicarei por que…

A segunda alternativa é criar 2 clusters e colocar DCs virtualizados em ambos. Esse cenário é interessante quando você pensa que os dois clusters não irão parar de funcionar ao mesmo tempo. Sendo assim, se um cluster cair, haverá um DC virtualizado no outro cluster que estará disponível para o cluster que está iniciando. Mesmo assim, se os dois cluesters pararem ao mesmo tempo, você terá problemas.

Já no Windows Server 2012, uma das diversas novidades sobre cluster é justamente essa dependencia do Active Directory para que o serviço inicie. No WS2012 o serviço do Cluster poderá iniciar com uma conta de serviço local, o que fará com que o serviço inicie e as funções do cluster possam iniciar. No caso de qualquer VM, como um DC virtualizado, isso permitirá que a VM inicie e o AD esteja disponível. Vale ressaltar que o fato do serviço do cluster iniciar, não garante que todas as funções iniciem. Por exemplo: O serviço do Excahnge precisa do AD de qualquer forma.

Essa novidade do WS2012 para serviço de Cluster resolve o cenário onde todos os Domain Controllers estão virtualizados e em cluster. Neste cenário, se você tiver um cluster com DCs virtualizados e este cluster for desligado, no momento que se iniciar o cluster, o serviço irá subir, permitindo que as VMs que rodam neste cluster iniciem, pois a inicialização de VMs não é um serviço que depende do AD. Com as VMs ligadas e consequentemente, o AD de volta no ar, todos os serviços do cluester ficam dispoíveis. Para verificar as demais novidades sobre cluster no WS2012, acesse o link: http://technet.microsoft.com/en-us/library/hh831414.aspx. Sobre as novidades de cluster com AD, vá até http://technet.microsoft.com/en-us/library/hh831414.aspx#BKMK_AD.

Espero que esta dica tenha ajudado!
Até mais!

By

Virtualização de Domain Controllers – Parte 03

Olá Pessoal,

Mais um post da série que pretende dismistificar a virtualização de Domain Controllers. Nesse post vamos falar sobre a utilização de Snapshots em VMs que são Domain Controllers.

No último post comentei um pouco sobre a replicação entre Domain Controllers. A replicação é uma das atividades mais importantes do Active Directory, pois garante que todos os Domain Controllers tenham a mesma informação na base de dados.

Se você tem mais um Domain Controller (E você deveria ter!) a replicação deve ser monitorada para que não haja nenhum problrema dentro do seu ambiente. A replicação é feita por diversos componentes que garantem que todos os itens necessários estarão atualizados em todos os Domain Controllers. Sendo muito simplista, existem dois componentes que são importantes na resplicação e que precisam ser entendidos para que possamos continuar.

O primeiro é a informação de que um item é autoritativo naquele servidor. Imagine que um usuário trocou sua senha. Esse processo é feito na máquina do usuário que envia a informação de troca de senha do usuário para o Domain Controller mais próximo onde este usuário se autenticou. O DC com esta informação mais recente, marca esse item como autoritativo para que ele possa enviar esta informação aos outros DCs. Logo, tudas as novas informações são autoritativas no DC ao qual a modificação foi feita, seja troca de senha, criação de usuário, deleção de usuário e todo mais que altera-se na base do AD. Uma vez que este Domain Controller passou isso aos demais, a informação se torna autoritativa em todos.

Para que isso não vire uma bagunça, existem diversos outros componentes que garantem que a última informação sempre seja a que vale. E para que todos os DCs possam se entender, há um outro componente chamado USN ou Update Sequence Number (Número de Sequencia de Atualização). O USN garante que todos os Domain Controllers estão com a informação mais atual possível.

Logo, a utilização de todos estes componentes garantem que todos os DCs estejam atualizados. Porém, se você está com um Domain Controller virtualizado, há uma variável aqui que pode atrapalhar este processo. Trata-se do Snapshot.

Quando você tira o snapshot de uma VM, basicamente, você cria uma imagem desta VM em um momento no tempo. Para testes, desenvolvimento e qualquer coisa fora de produção, não há muito problema com isso. Especificamente para o AD o Snapshot pode ser um grande problema. Na verdade para qualquer tipo de banco de dados onde você precisa replicar as informações, isso será um problema.

Vamos supor que você tem 4 Domain Controllers e resolve tirar um snapshot deles em uma terça-feira as 12:00. Na quarta-feira as 12:00 você percebe que um dos DCs apresenta uma falha. Para resolver o problema rapidamente, você resolve aplicar o snapshot que tinha do DC. Isso, porém, fará com que o DC que teve o snapshot aplicado ache que a informação de USN, digamos 90, é a mais atual pois isso é autoritativo para ele. Os outros DCs estão, digamos, com o USN em 120, ou seja, outras alterações ocorreram entre teça-feira as 12:00 e quarta-feira as 12:00.

Neste momento, este DC irá interromper a replicação pois estes DCs estão divergindo na informação mais atual. Para resolver este problema, você deverá recuperar o backup do AD não-autoritativo e aguardar a replicação dos outros DCs para este DC recuperado.

Até o Windows Server 2008 R2, essa era a forma de operação. Ou seja, se ainda não está rodando o Windows Server 2012, tome muito cuidado com snapshot de DCs.

Já se você está utilizando o Windows Server 2012 como Host de seu ambiente de Virtualização e o DC também é Windows Server 2012, esse problema não ocorre. Isso por que no AD do WS2012 uma informação é verificada após a aplicação de um Snapshot, o Virtualization ID. Este item basicamente comprova que um snapshot foi aplicado nesta VM. Com essa informação, o AD é capaz de marcar o USN como não-autoritativo na VM que é um Domain Controller. Sabendo que não é autoritativo, este Domain Controller inicia o processo de replicação dos outros DCs normalmente.

 

image

Resumo: Se você utiliza Windows Server 2008 R2, seja como Host ou VM, não utilize Snapshot de VM. Se você utiliza WS2012 como Host e DC em máquina virtual, enjtão isso não será um problema.

Até mais!

By

Virtualização de Domain Controllers – Parte 02

Olá Pessoal,

Continuando nossa série de posts sobre virtualização de Domain Controllers, hoje quero falar sobre um assunto muito importante que se dá pouca importancia:  Sincronismo de Horário.

Muita gente acaba administrando o Active Directory sem se dar conta de alguns itens importantes sobre o mesmo. O AD é um serviço de diretório que pode ter uma arquitetura simples, para atender pequenos ambientes e com pouca configuração está pronto para funcionar, ou pode ter uma arquitetura bem complexa para atender organizações maiores. Porém, em ambos os casos, o funcionamento é o mesmo.

Desde o Active Directory na versão do Windows 2000 Server, o AD é multimaster, o que significa que todos os Domain Controllers podem escrever na base do AD. Isso é muito bom pois torna o AD muito simples para se implementar Alta disponibilidade. Porém, a reaplicação se torna algo extremamente importante. Mas o que vem ao caso aqui, é que mesmo sendo multimaster, algumas operações são executadas apenas por alguns servidores específicos. São os FSMO ou Flexible single master operation. São 5 FSMO, e para Virtualização uma delas é muito importante, o PDC Emulator.

Uma das funções do PDC Emulator é ser o ponto principal de Horário para os outros Domain Controllers, que por sua vez, fornecem o horário correto para as estações.

O problema é que no Hyper-V, quando você cria uma VM, a configuração padrão é que haja uma sincronia de horário entre VM e Host. Para um Domain Controller, isso é um problema, pois ele deveria estar seguindo a hierarquia do Active Directory.

A resolução deste problema é muito simples. Para VMs que são Domain Controllers, é preciso desmarcar a opção de sincronismo de horário nas opções de Integration Services.

image

Até mais!

By

Virtualização de Domain Controllers – Desvendando mitos!

Olá Pessoal,

Quando falamos de virtualização, um dos assuntos que causa um pouco de polêmica, é a relação do Active Directory com a plataforma de virtualização. Para jogar um pouco de luz sobre este assunto, pretendo fazer uma série de posts para que possamos dismistificar essas questões. Na verdade, pretendo fazer uma reflexão do que está neste documento oficial, que se você quiser ler antes de ler os posts, fique a vontade.

- Base de dados do AD em local padrão:

A base de dados do AD é composta por diversos componentes como Base de Dados, Arquivos de Log, Log de Transação e etc. Para preservar a integridade desta base, o AD utiliza um método de escrita sem buffer e tenta desabilitar um recurso de cache de escrita de disco nos volumes onde esta base se encontra. O problema com a virtualização é que o disco tem que suportar um recurso no disco virtual chamado de SCSI Emulation.

Existem 2 pontos que devem ser observados aqui:

Primeiro Ponto: Quando você promove o servidor a Domain Controller, no assistente de promoção, um dos passos é escolher o local onde a base e logs do AD serão armazenados. Este assistente sugere que você armazene esta base e log no disco C: que é, provavelmente, o seu disco de sistema, boot e etc. O primeiro motivo que você deve armazenar a base e log fora deste local é performance. Obviamente, existem outros pontos para que você não deixe esta base e log no volume do sistema, mas para nossa explicação aqui, o ponto mais importante é que o disco de boot em VMs do Hyper-V tem que ser um disco IDE. O que nos leva ao segundo ponto:

Segundo Ponto: O Hyper-V possui 2 tispos de barramento de disco. IDE e SCSI. Os discos IDE são discos que podem ser entregues para as VMs mesmo sem o funcionamento do Integration Components. Por isso é utilizado para disco de Boot. Porém, para que o AD do Domain Controller virtualizado consiga passar para o Host o processo de escrita sem cache, o disco tem que suportar isso. E para que o disco suporte, ele tem que ser SCSI. Logo, o disco onde você armazena a base e log do AD no Domain Controller Virtual devem ser SCSI. Veja abaixo, a diferença nas configurações de uma VM:

Discos

Essa foi a primeira dica para virtualizar Domain Controllers sem problemas em seu ambiente. Em breve volto com mais dicas para vocês.

Até mais!