Dois-je toujours avoir un contrôleur de domaine physique, même après Server 2012?

À l'époque antérieure à Windows Server 2012, la recommandation semblait être d'avoir au moins un contrôleur de domaine physique assis à côté de vos contrôleurs de domaine virtualisés.

Une justification à cela était que si vos hôtes Hyper-V étaient en cluster, alors ils avaient besoin d'un contrôleur de domaine pour être contactable lors du démarrage. Cela me semble totalement logique.

Cependant, j'entendais souvent des gens dire qu'il est toujours important d'avoir un contrôleur de domaine physique même si vous n'avez pas de configuration en cluster (par exemple, dans une configuration simple avec un seul serveur Hyper-V exécutant deux machines virtuelles, une dont un DC). La justification de cela semblait (et je ne pourrais jamais être tout à fait sûr) que vous auriez toujours un problème dans le sens où lorsque l'hôte Hyper-V démarre pour la première fois, aucun DC n'est présent sur le réseau. Les informations d'identification mises en cache signifient que vous pouvez toujours vous connecter, mais qu'en est-il de tous ces bits qui se produisent lors du démarrage, ce qui signifie qu'un DC est disponible? Est-ce vraiment un problème? Existe-t-il réellement des opérations qui pourraient s'exécuter uniquementau démarrage qui causera un problème? Des stratégies de groupe par exemple? Ce que je demande fondamentalement, c'est si l'argument DC physique tient vraiment le coup lorsque le clustering est impliqué, ou y avait-il (avant 2012) un argument technique important sans le clustering? Cet article d'Altaro (voir la section «Le mythe du poulet et des œufs») suggère qu'il n'y en a pas besoin, mais je ne suis toujours pas sûr.

Passons maintenant à la deuxième (et principale) partie de ma question:

Windows Server 2012 a introduit plusieurs fonctionnalités destinées à résoudre les problèmes liés à la virtualisation des contrôleurs de domaine, notamment:

1. ID de génération de VM - Cela a résolu le problème de restauration de l'USN qui signifiait que la capture instantanée (ou plus précisément, la restauration d'une capture instantanée) n'était pas prise en charge / une très mauvaise idée
2. Cluster Bootstrapping - Cela a résolu le problème "poulet et oeuf" entourant le clustering de basculement que j'ai mentionné ci-dessus. Le clustering de basculement ne nécessite plus la présence d'un contrôleur de domaine lors du démarrage.

Ma deuxième question est donc similaire à la première, mais cette fois pour 2012+. En supposant que le vDC et l'hôte sont 2012+ et que vous retirez le clustering de l'équation, y a-t-il d'autres problèmes comme ceux mentionnés ci-dessus qui signifient que je devrais toujours considérer un DC physique? Dois-je toujours envisager d'avoir un contrôleur de domaine physique à côté de mon hôte Hyper-V 2012 / 2012R2 unique, non en cluster, qui possède un seul contrôleur de domaine virtualisé? J'entends certaines personnes suggérer de mettre AD sur l'hôte Hyper-V, mais je n'aime pas cette idée pour diverses raisons (le cache WB étant désactivé pour commencer).

En remarque, ma question suppose implicitement qu'il est logique que votre hôte Hyper-V soit joint au domaine pour améliorer la gérabilité. Cette affirmation résiste-t-elle à l'examen?

MISE À JOUR:

Après avoir lu certaines réponses, j'ai pensé que je pouvais formuler les choses légèrement différemment pour aller au cœur de ce que je demandais:

Même avec les améliorations apportées en 2012 et plus tard, le fait demeure que sans aucun contrôleur de domaine physique ou contrôleur de domaine virtuel sur un autre hôte, l'hôte démarre toujours lorsqu'il n'y a pas de contrôleur de domaine disponible. Est-ce vraiment un problème? Dans un sens, je suppose que c'est la même question (ou très similaire) si vous supprimez complètement la virtualisation de l'image. Si vous démarrez régulièrement des serveurs membres avant tout contrôleur de domaine, est-ce un problème?

Moi aussi, je ne ferais pas de l'hôte Hyper-V un contrôleur de domaine.

Quant à savoir si vous devez ou non avoir un contrôleur de domaine physique, mon avis est qu'avec les changements que Microsoft a mis en œuvre concernant les contrôleurs de domaine virtualisés en général et le démarrage de cluster sans DC en particulier, je ne vois pas personnellement la nécessité de, ni je ne préconise ayant un DC physique. La maintenance d'un contrôleur de domaine physique semble contraire à la nature du déplacement de votre infrastructure vers une plate-forme de virtualisation. Virtualiser l'intégralité de mon infrastructure, mais tout dépend d'un seul DC physique disponible? À quoi ça sert?

Il existe des moyens de limiter votre "exposition" tout en virtualisant vos contrôleurs de domaine. Une façon serait de déployer plusieurs contrôleurs de domaine sur différents hôtes de votre cluster et d'utiliser l'anti-affinité pour les garder séparés en cas de défaillance d'un hôte (en fonction du nombre d'hôtes dans le cluster).

Bien que la réponse de Greg comprenne un lien vers certaines recommandations MS, cet article a néanmoins deux ans et traite de Windows Server 2008 et 2008 R2. Je ne considérerais pas cet article comme la meilleure pratique actuelle en ce qui concerne Windows Server 2012 et 2012 R2. Je ne trouve pas de document MS officiel, mais ce type est considéré comme une autorité de premier plan sur Hyper-V - http://www.aidanfinn.com/?p=13171

L'une des raisons de conserver un contrôleur de domaine physique par domaine est la suivante: en cas d'incident majeur qui affecte l'hôte ou bloque le stockage de trames pour les contrôleurs de domaine virtualisés, vous disposez d'au moins un contrôleur de domaine physique avec stockage local pour effectuer la récupération et maintenir la continuité. Microsoft continue d'effectuer cette vérification et de faire cette recommandation lors des RAP Active Directory (évaluation et planification des risques).

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

"Maintenez des contrôleurs de domaine physiques dans chacun de vos domaines. Cela réduit le risque de dysfonctionnement de la plate-forme de virtualisation qui affecte tous les systèmes hôtes qui utilisent cette plate-forme."

J'ai l'impression que vous cherchez une réponse sur une ligne, alors voici:

Vous devriez avoir un contrôleur de domaine physique si vous ne faites pas confiance à la capacité de votre environnement virtuel à résister aux pannes.

Nous pourrions nous attarder sur les particularités et les exceptions de chaque scénario, mais je pense que cela touche à la racine de la question.

Prenons les grappes de l'équation et concentrons-nous sur la seule ligne de votre question qui me fait frémir.

Dois-je toujours envisager d'avoir un contrôleur de domaine physique à côté de mon hôte Hyper-V 2012 / 2012R2 unique, non en cluster, qui possède un contrôleur de domaine virtualisé unique ?

Pourquoi, pourquoi, pourquoi voudriez-vous un seul DC? Dans un environnement donné, nous essayons d'éviter d'avoir des points de défaillance uniques pour une infrastructure donnée. Les contrôleurs de domaine sont votre pain et beurre - ils fournissent DNS, l'épine dorsale d'Active Directory. Sérieusement, reconstruisez un ordinateur de bureau Windows 7 sur 2008R2 et faites-en la promotion. Il y a toujours de bonnes raisons pour un DC physique.

Hyper-V avec AD DS? Non, juste non. Premièrement, Microsoft ne prend pas en charge cela. Deuxièmement, comme vous l'avez mentionné, la gestion des sauvegardes deviendra pénible en fonction de la configuration de votre disque. Sans oublier - la beauté de la virtualisation est la possibilité de retirer des hôtes physiques aussi rapidement que nous pouvons les construire (et j'apprécie qu'un dcpromo n'est pas énorme (selon la taille de votre environnement)) et l'hébergement d'AD DS complique simplement importe. Vous introduisez également une autre complexité Windows Time.

Personnellement, je laisse mes hôtes Hyper-V autonomes hors du domaine, mais en réalité, je n'ai aucun argument réel pour l'une ou l'autre configuration.

Pour répondre à la dernière question sur la question de savoir s'il s'agit réellement d'un problème: j'ai remarqué que mes hôtes Hyper-V avec RDP activé, mais nécessitant NLA, n'autorisent pas RDP tant que je n'ai pas redémarré le service Network Location Awareness s'il n'y a pas de DC up quand il démarre. J'ai eu des problèmes occasionnels avec la connexion à VMMS à distance à ces points également, mais seulement lorsque quelque chose d'autre était également cassé. Lorsque vous ne pouvez pas utiliser RDP ou vous connecter à distance au gestionnaire Hyper-V, il est vraiment difficile de déterminer ce qui est cassé et de réparer les choses. Garder un DC physique autour de moi a empêché cela de m'arriver à tout moment.