Ainda devo ter um controlador de domínio físico, mesmo após o Server 2012?


30

Nos dias anteriores ao Windows Server 2012, a recomendação parecia ter pelo menos um controlador de domínio físico sentado ao lado de seus controladores de domínio virtualizados.

Uma justificativa para isso era porque, se os hosts do Hyper-V estavam em cluster, eles exigiam que um controlador de domínio fosse contatado durante a inicialização. Isso faz total sentido para mim.

No entanto, eu sempre ouvia as pessoas dizerem que ainda é importante ter um controlador de domínio físico, mesmo que você não tenha um cluster configurado (por exemplo, em uma configuração simples com um único servidor Hyper-V executando duas VMs, uma dos quais é um CD). A justificativa para isso parecia (e eu nunca poderia ter certeza) de que você ainda teria um problema no sentido de que, quando o host Hyper-V for inicializado pela primeira vez, não haverá um controlador de domínio na rede. As credenciais em cache significam que você ainda pode fazer logon, mas e todos os bits que ocorrem durante a inicialização que significam ter um controlador de domínio por perto? Isso é realmente um problema? Na verdade, existem operações que podem executar apenasna inicialização que causará um problema? Alguma política de grupo, por exemplo? O que eu estou basicamente perguntando é: o argumento físico do DC realmente retém a água quando o cluster está envolvido, ou houve (antes de 2012) um caso técnico significativo para isso sem o cluster? Este artigo da Altaro (consulte a seção "Mito do ovo e da galinha") sugere que não há necessidade, mas ainda não tenho certeza.

Agora, para a segunda parte (e principal) da minha pergunta:

O Windows Server 2012 introduziu vários recursos direcionados para solucionar os problemas da virtualização de controladores de domínio, incluindo:

  1. ID de geração da VM - solucionou o problema de reversão da USN que significava que o instantâneo (ou mais especificamente, o retorno a um instantâneo) não era suportado / era uma péssima ideia
  2. Bootstrapping de cluster - abordou o problema "galinha e ovo" em torno do cluster de failover que mencionei acima. O clustering de failover não exige mais que um controlador de domínio esteja presente durante a inicialização.

Portanto, minha segunda pergunta é semelhante à primeira, mas desta vez para 2012 ou mais. Supondo que o vDC e o host tenham mais de 2012 e que você tire o agrupamento da equação, existem outros problemas como os mencionados acima que significam que eu ainda devo considerar um DC físico? Ainda devo considerar ter um controlador de domínio físico ao lado do meu host 2012 / 2012R2 Hyper-V único e sem cluster que possui um único controlador de domínio virtualizado? Ouvi algumas pessoas sugerindo colocar o AD no host Hyper-V, mas não gosto dessa ideia por vários motivos (o cache do WB é desativado para começar).

Como observação lateral, minha pergunta implica implicitamente que faz sentido ter seu host Hyper-V ingressado no domínio para melhorar a capacidade de gerenciamento. Esta afirmação resiste ao escrutínio?

ATUALIZAR:

Depois de ler algumas respostas, ocorreu-me que eu poderia expressar as coisas de maneira um pouco diferente para chegar ao âmago do que estou perguntando:

Mesmo com as melhorias em 2012 e posteriores, ainda permanece o fato de que, sem nenhum controlador de domínio físico ou controlador de domínio virtual em outro host, o host ainda inicializa quando não há controlador de domínio disponível. Isso é realmente um problema? Em certo sentido, suponho que seja a mesma pergunta (ou muito semelhante) se você tirar a virtualização completamente de cena. Se você iniciar servidores membros antes de qualquer controlador de domínio regularmente, isso é um problema?


4
Pessoalmente, eu nunca instalaria o AD no seu host Hyper-V. Tire tudo do cluster relacionado à situação no momento. Você perde seu primeiro e único controlador de domínio virtual - você perde sua única fonte de DNS.
PnP

Respostas:


11

Eu também não faria do host do Hyper-V um controlador de domínio.

Quanto à questão de saber se você deve ou não ter um controlador de domínio físico, minha opinião é que, com as mudanças que a Microsoft implementou em relação aos controladores de domínio virtualizados em geral e ao bootstrap de cluster sem controlador de domínio especificamente, eu pessoalmente não vejo a necessidade e não defendo tendo um CD físico. Manter um controlador de domínio físico parece contra-intuitivo a natureza de mover sua infraestrutura para uma plataforma de virtualização. Virtualize toda a minha infraestrutura, mas tudo depende de um único controlador de domínio físico disponível? Qual o sentido disso?

Existem maneiras de limitar sua "exposição" enquanto ainda virtualiza seus controladores de domínio. Uma maneira seria implantar vários controladores de domínio em hosts diferentes no cluster e usar a antin afinidade para mantê-los separados no caso de uma falha no host (dependendo de quantos hosts estiverem no cluster).

Embora a resposta de Greg inclua um link para algumas recomendações da Microsoft, esse artigo ainda tem dois anos e aborda o Windows Server 2008 e 2008 R2. Eu não consideraria esse artigo a melhor prática atual em relação ao Windows Server 2012 e 2012 R2. Não consigo encontrar um documento oficial do MS, mas esse cara é considerado uma das principais autoridades do Hyper-V - http://www.aidanfinn.com/?p=13171


Obrigado Joe. Na verdade, li o artigo de Aidan há um tempo atrás e ele parcialmente informou minha pergunta. O que me impressiona é que, seguindo-o logicamente, não havia realmente um caso para um DC físico antes de 2012, a menos que você executasse um ambiente em cluster (além de talvez tornar a instalação 'cluster pronta'). É por isso que acrescentei outra parte sobre as pessoas que ainda justificam a necessidade de um pDC, mesmo sem clustering, o que não parece ter mudado com 2012.
dbr

você concorda com o meu comentário acima de que, se você resolver o problema de agrupamento, a situação realmente não mudou entre 2008 e 2012?
DBR

@dbr Gostaria apenas de acrescentar à resposta de Joe que, para um hyper-v (não xen ou esx), eu testaria o hyper-mmc antes. Como aconteceu comigo, um host morto com o DC e o hyperv mmc precisavam de um AD vivo para abrir. Fiquei bloqueado mesmo se logado como administrador de domínio com a credencial em cache. Pode ser corrigido com a atualização mais recente, mas é um fato importante. (ao contrário do esx que pode usar o usuário embutido, pois você ainda pode abrir o vsphere ou o vcenter)
yagmoth555 - GoFundMe Monica

Só quero adicionar outras maneiras de melhorar a resiliência: ter mais de um cluster de host de virtualização (no mesmo local ou em outros locais) e / ou criar uma VPN no Azure (ou AWS - Azure tem alguns benefícios para as lojas da Microsoft) e colocar um DC ou dois lá em cima.
Todd Wilcox

18

Uma justificativa para reter um controlador de domínio físico por domínio é que, se houver um incidente grave que afete o host ou atrapalhe o armazenamento de quadros dos controladores de domínio virtualizados, você teria pelo menos um controlador de domínio de domínio físico com armazenamento local para executar a recuperação e manter a continuidade. A Microsoft continua a executar essa verificação e faz essa recomendação durante os RAPs do Active Directory (Avaliação e Planejamento de Riscos).

https://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv%28v=ws.10%29.aspx

"Mantenha controladores de domínio físicos em cada um dos seus domínios. Isso reduz o risco de um mau funcionamento da plataforma de virtualização que afeta todos os sistemas host que usam essa plataforma".


2
Mas não tenho certeza se isso faz sentido - veja, por exemplo, que uma empresa é 100% virtual com o controlador de domínio e faz backups regulares e possui 3 dc em 2 continentes (2 na europa, 1 nos eua) ... difícil imaginar qualquer coisa aqui que exploda de uma maneira que torne as coisas não recuperáveis.
TomTom

Eu acho que o ponto que eles estão tentando enfatizar é se houver algum tipo de problema que afeta o Hyper-V como um todo, você seria (temporariamente) ferrado até poder restaurar um controlador de domínio, onde, como ter um pDC significaria menos interrupção. Não tenho certeza se eu concordaria, já que você seria muito ferrado de qualquer maneira se houvesse um problema de interrupção no Hyper-V!
DBR

11
Agradável e elegante, mas novamente totalmente irrelevante, A menos que você tenha uma parte significativa de sua infraestrutura fora do Hyper-V. O DC está funcionando, mas compartilha compartilhamentos de arquivos, sharepoint, troca, impressão e todas as outras coisas inativas - significa que eu prefiro não me importar com o DC estar novamente ativo;) Ele geralmente acaba com "vários DCs e faz backups" e é esse o caso em ambos os lados (Hyper-V e físico).
TomTom

@ TomTom Isso é o que eu estava enganando com o meu comentário "você seria muito ferrado de qualquer maneira" :) Eu estava assumindo que praticamente todo o resto seria virtualizado de qualquer maneira. Completamente concordam que se trata de "ter vários backups DC e fazer"
DBR

A @TomTom Company em que trabalho também é totalmente virtual para a infraestrutura do AD. E tem sido isso desde o W2K3. Mas não usamos o HyperV: ESX até o fim. 2 conjuntos separados de infraestrutura de cluster ESX em cada continente. Cada domínio possui (no mínimo) 3 controladores de domínio: 1 controlador de domínio em outro continente e 1 controlador de domínio em cada um dos 2 ambientes ESX no continente "doméstico".
quer

10

Sinto que você está procurando uma resposta em uma linha, então aqui está:

Você deve ter um controlador de domínio físico se não confiar na capacidade do seu ambiente virtual de suportar falhas.

Poderíamos nos aprofundar nas peculiaridades e exceções de cada cenário, mas acho que isso atinge a raiz da questão.


3

Vamos pegar os grupos da equação e focar na única linha da sua pergunta que me faz estremecer.

Ainda devo considerar ter um controlador de domínio físico ao lado do meu host 2012 / 2012R2 Hyper-V único e sem cluster que possui um único controlador de domínio virtualizado?

Por que, por que, por que, você quer um único CD? Em qualquer ambiente, tentamos evitar pontos únicos de falha para qualquer infraestrutura. Os DCs são o seu pão com manteiga - eles fornecem o DNS, a espinha dorsal do Active Directory. Sério, recrie um PC com Windows 7 Desktop em 2008R2 e promova-o. Sempre existe um argumento forte para um CD físico.

Hyper-V com AD DS? Não, apenas não. Em primeiro lugar, a Microsoft não suporta isso. Em segundo lugar, como você mencionou, o manuseio de backups se tornará um problema dependente da configuração do seu disco. Sem mencionar - a beleza da virtualização é a capacidade de retirar hosts físicos o mais rápido que podemos construí-los (e eu aprecio um dcpromo não é um grande negócio (dependendo do tamanho do seu ambiente)) e a hospedagem do AD DS apenas complica assuntos. Você também apresenta outra complexidade de horário do Windows.

Pessoalmente, deixo meus hosts Hyper-V independentes fora do domínio, mas, na realidade, não tenho argumentos reais para nenhuma das configurações.


3
A maior parte da sua resposta é desnecessariamente crítica ao apresentar argumentos inteiramente válidos, mas que nada têm a ver com a pergunta. É claro que vários CDs são quase sempre obrigatórios - a parte citada está sendo usada para ilustrar um ponto / pergunta. O combo HV + AD novamente é apenas uma observação, e acho que fiquei bem claro que também não sou um amante do combo.
DBR

2
Se "sempre existe um argumento forte para um CD físico". [vs. um segundo vDC, por exemplo] - você poderia explicar esse caso? Essa é realmente a minha pergunta.
DBR

1

Para responder à última pergunta sobre se isso realmente é um problema: notei que meus hosts Hyper-V com RDP ativado, mas exigindo NLA, não o permitem até que eu reinicie o serviço de reconhecimento de local de rede, se não houver um DC up quando inicializa. Também tive problemas ocasionais ao conectar-se ao VMMS remotamente nesses pontos, mas apenas quando outra coisa também foi interrompida. Quando você não pode efetuar o RDP ou conectar-se ao gerenciador do Hyper-V remotamente, é realmente difícil descobrir o que está quebrado e consertar as coisas. Manter um CD físico por perto impediu que isso acontecesse comigo a qualquer momento.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.