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 nécessitaient un DC pour être joignable au démarrage. Cela a un sens total pour moi.
Cependant, j'entendais souvent les gens dire qu'il est toujours important d'avoir un physique DC même si vous n'avez pas de configuration en cluster (par exemple dans une configuration simple avec un seul Hyper- Serveur V exécutant deux machines virtuelles, dont l'un est un contrôleur de domaine). 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ù au démarrage de l'hôte Hyper-V, il n'y a pas DC 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 pendant le démarrage, cela signifie avoir un DC = around est bénéfique? Est-ce réellement un problème? Y a-t-il réellement des opérations qui pourraient s'exécuter seulement au démarrage qui causerait un problème? Toutes les stratégies de groupe par exemple? Ce que je demande essentiellement est, est-ce que l'argument physique DC ne tient vraiment la route que lorsque le clustering est impliqué, ou y avait-il (avant 2012) un argument technique important sans clustering? This article = depuis 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:
- ID de génération de machine virtuelle - Cela a résolu le problème de restauration USN qui signifiait un instantané (ou plus précisément, un retour à un instantané) n'était pas pris en charge/une très mauvaise idée
- Amorçage du cluster - 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 DC 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 DC à côté de mon hôte Hyper-V 2012/2012R2 unique non clusterisé qui a un seul virtualisé DC sur 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 de 2012 et ultérieures, 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 DC disponible. Est-ce réellement 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. Si vous démarrez régulièrement les serveurs membres avant les contrôleurs 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. Le maintien d'un physique DC semble contre-intuitif à la nature du déplacement de votre infrastructure vers une plate-forme de virtualisation. Virtualisez toute mon infrastructure mais tout dépend d'un seul physique DC étant à 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
Une raison pour conserver un physique DC par domaine est s'il y a un incident majeur qui affecte l'hôte ou détruit le stockage de trame pour les contrôleurs de domaine virtualisés, vous auriez au moins un physique DC 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 pendant les RAP Active Directory (évaluation et planification des risques).
"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 devez avoir un physique DC 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 physique DC à côté de mon hôte Hyper-V 2012/2012R2 unique non clusterisé qui a un nique virtualisé DC dessus?
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 un cas fort 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 un problème dépendant 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 une grosse affaire (selon la taille de votre environnement)) et l'hébergement AD DS complique simplement les choses. 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 RDP qu'après avoir redémarré le service Network Location Awareness s'il n'y a pas de DC up lors du démarrage. J'ai eu des problèmes occasionnels avec la connexion à VMMS à distance à ces points également, mais uniquement lorsque quelque chose d'autre était également cassé. Quand vous ne pouvez pas RDP, ou se connecter au gestionnaire Hyper-V à distance, il est vraiment difficile de comprendre ce qui est cassé et de réparer les choses. Garder un physique DC autour a empêché cela de m'arriver à tout moment.