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


30

À 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?


4
Personnellement, je n'installerais jamais AD sur votre hôte Hyper-V. Retirez tout ce qui concerne le cluster de la situation pour le moment. Vous perdez votre seul et unique DC virtuel - vous perdez votre seule source de DNS.
PnP

Réponses:


11

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


Merci Joe. J'ai lu l'article d'Aidan il y a quelque temps et cela a en partie éclairé ma question. Ce qui me frappe, c'est que, suivant logiquement, il n'y avait pas vraiment de cas pour un DC physique avant 2012, sauf si vous exécutiez un environnement en cluster (autre que peut-être que la configuration était `` prête pour le cluster ''). C'est pourquoi j'ai ajouté l'autre élément sur les personnes qui justifient toujours la nécessité d'un pDC même sans clustering, ce qui ne semble pas avoir changé avec 2012.
dbr

seriez-vous d'accord avec mon commentaire ci-dessus selon lequel si vous supprimez le problème de clustering, la situation n'a pas vraiment changé entre 2008 et 2012?
dbr

@dbr J'ajouterais seulement à la réponse de joe que pour un hyper-v (pas xen ou esx) je testerais l'hyper-v mmc avant. Comme cela m'est arrivé, un hôte mort avec le DC dessus, et l'hyperv mmc avaient besoin d'une AD vivante pour s'ouvrir. J'étais coincé même si j'étais connecté en tant qu'administrateur de domaine avec les informations d'identification mises en cache. Pourrait être corrigé avec la dernière mise à jour, mais c'est un fait important. (contrairement à esx qui peut utiliser l'utilisateur intégré, car vous pouvez toujours ouvrir vsphere ou vcenter)
yagmoth555 - GoFundMe Monica

Je veux juste ajouter d'autres façons d'améliorer la résilience: avoir plus d'un cluster hôte de virtualisation (au même emplacement ou dans d'autres emplacements) et / ou créer un VPN pour Azure (ou AWS - Azure a quelques avantages pour les boutiques MS) et mettre un DC ou deux là-haut.
Todd Wilcox

18

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."


2
Je ne sais pas si cela a du sens, cependant - voyez, par exemple, je connais une entreprise 100% virtuelle avec le DC et ils font des sauvegardes régulières et ont 3 cc sur 2 continents (2 en Europe, 1 aux États-Unis) .... dur d'imaginer quoi que ce soit ici qui souffle d'une manière qui rend les choses non récupérables.
TomTom

Je suppose que le point qu'ils essaient de faire est qu'il y ait une sorte de problème qui affecte Hyper-V dans son ensemble, alors vous seriez (temporairement) foutu jusqu'à ce que vous puissiez restaurer un DC, où avoir un pDC signifierait moins de perturbation. Je ne suis pas sûr que je serais d'accord, car vous seriez plutôt foutu de toute façon s'il y avait un problème de panne à l'échelle de Hyper-V!
dbr

1
Agréable et dandy, mais encore une fois totalement hors de propos À MOINS que vous ayez une partie importante de votre infrastructure hors d'Hyper-V. Le DC fonctionne mais partage les fichiers, le point de partage, l'échange, l'impression et toutes les autres choses - signifie que je ne me soucie pas du fait que le DC soit de nouveau opérationnel;) des deux côtés (Hyper-V et physique).
TomTom

@TomTom C'est à cela que j'évitais avec mon commentaire "tu serais plutôt foutu de toute façon" :) Je supposais à peu près tout le reste serait virtualisé de toute façon. Entièrement d'accord pour dire que cela revient à "avoir plusieurs DC et faire des sauvegardes"
dbr

La société @TomTom pour laquelle je travaille est également entièrement virtuelle pour l'infrastructure AD. Et cela depuis W2K3. Mais nous n'utilisons pas HyperV: ESX complètement. 2 ensembles distincts d'infrastructure de cluster ESX sur chaque continent. Chaque domaine a (au minimum) 3 DC: 1 DC sur un autre continent et 1 DC dans chacun des 2 environnements ESX sur le continent "domestique".
Tonny

10

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.


3

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.


3
La plupart de votre réponse est inutilement critique en faisant valoir des points qui sont entièrement valables, mais qui n'ont rien à voir avec la question. Bien sûr, plusieurs DC sont presque toujours un must - la partie citée est utilisée pour illustrer un point / une question. Le combo HV + AD n'est encore vraiment qu'une note secondaire, et je pense que j'étais assez clair que je ne suis pas non plus un amoureux du combo.
dbr

2
S'il y a "un argument solide pour un DC physique". [contre. un deuxième vDC par exemple] - pourriez-vous expliquer ce cas? C'est vraiment ma question.
dbr

1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.