Éléments à prendre en compte lorsque vous hébergez des contrôleurs de domaine Active Directory dans des environnements d’hébergement virtuel

Cet article décrit les problèmes qui affectent un contrôleur de domaine Windows Server s’exécutant en tant que système d’exploitation invité dans des environnements d’hébergement virtuel. Il décrit également les éléments à prendre en compte lorsqu’un contrôleur de domaine s’exécute dans un environnement d’hébergement virtuel.

Produits concernés : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 888794

Résumé

Un environnement d’hébergement virtuel vous permet d’exécuter plusieurs systèmes d’exploitation invités sur un seul ordinateur hôte en même temps. Le logiciel hôte virtualise les ressources suivantes :

• UC
• Mémoire
• Disque
• Réseau
• Appareils locaux

En virtualisant ces ressources sur un ordinateur physique, le logiciel hôte vous permet d’utiliser moins d’ordinateurs pour déployer des systèmes d’exploitation à des fins de test et de développement, et dans des rôles de production. Certaines restrictions s’appliquent à un contrôleur de domaine Active Directory qui s’exécute dans un environnement d’hébergement virtuel. Ces restrictions ne s’appliquent pas à un contrôleur de domaine qui s’exécute sur un ordinateur physique.

Cet article décrit les éléments à prendre en compte lorsqu’un contrôleur de domaine Windows Server s’exécute dans un environnement d’hébergement virtuel. Les environnements d’hébergement virtuel incluent :

• Virtualisation Windows Server avec Hyper-V.
• Famille de produits de virtualisation VMware.
• Famille de produits de virtualisation Novell.
• Famille de produits de virtualisation Citrix.
• Tout produit figurant dans la liste de l’hyperviseur dans le Programme de validation de la virtualisation de serveur (SVVP).

Pour plus d’informations sur la status actuelle de robustesse et de sécurité du système pour les contrôleurs de domaine virtualisés, consultez l’article suivant :

Virtualisation des contrôleurs de domaine à l’aide d’Hyper-V.

L’article Virtualisation des contrôleurs de domaine fournit des recommandations générales qui s’appliquent à toutes les configurations. La plupart des considérations décrites dans cet article s’appliquent également aux hôtes de virtualisation tiers. Il peut inclure des recommandations et des paramètres spécifiques à l’hyperviseur que vous utilisez, notamment :

• Comment configurer la synchronisation de l’heure pour les contrôleurs de domaine.
• Comment gérer les volumes de disque pour l’intégrité des données.
• Comment tirer parti de la prise en charge de l’ID de génération dans les scénarios de restauration ou de migration.
• Comment gérer l’allocation et les performances de la RAM et des cœurs de processeur sur l’hôte de la machine virtuelle.

Cet article complète l’article Virtualisation des contrôleurs de domaine en fournissant d’autres conseils et considérations qui n’étaient pas dans l’étendue de l’article Virtualisation des contrôleurs de domaine.

Éléments à prendre en compte lorsque vous hébergez des rôles de contrôleur de domaine dans un environnement d’hébergement virtuel

Lorsque vous déployez un contrôleur de domaine Active Directory sur un ordinateur physique, certaines exigences doivent être satisfaites tout au long du cycle de vie du contrôleur de domaine. Le déploiement d’un contrôleur de domaine dans un environnement d’hébergement virtuel ajoute certaines exigences et considérations, notamment :

• Le service Active Directory permet de préserver l’intégrité de la base de données Active Directory en cas de perte de courant ou de défaillance. Pour ce faire, le service exécute des écritures sans débogage et tente de désactiver le cache d’écriture sur disque sur les volumes qui hébergent la base de données Active Directory et les fichiers journaux. Active Directory tente également de fonctionner de cette manière s’il est installé dans un environnement d’hébergement virtuel.

  Si le logiciel de l’environnement d’hébergement virtuel prend correctement en charge un mode d’émulation SCSI qui prend en charge l’accès unitaire forcé (FUA), les écritures sans tampon effectuées par Active Directory dans cet environnement sont passées au système d’exploitation hôte. Si FUA n’est pas pris en charge, vous devez désactiver manuellement le cache d’écriture sur tous les volumes du système d’exploitation invité qui hébergent :

  • la base de données Active Directory
  • les journaux d’activité
  • fichier de point de contrôle

  Remarque

  • Vous devez désactiver le cache d’écriture pour tous les composants qui utilisent le moteur de stockage extensible (ESE) comme format de base de données. Ces composants incluent Active Directory, le service de réplication de fichiers (FRS), le service WINS (Windows Internet Name Service) et le protocole DHCP (Dynamic Host Configuration Protocol).
  • En guise de meilleure pratique, envisagez d’installer des blocs d’alimentation non modifiables sur des hôtes de machine virtuelle.

• Un contrôleur de domaine Active Directory est destiné à exécuter le mode Active Directory en continu dès qu’il est installé. N’arrêtez pas ou ne suspendez pas la machine virtuelle pendant une période prolongée. Lorsque le contrôleur de domaine démarre, la réplication d’Active Directory doit se produire. Assurez-vous que tous les contrôleurs de domaine effectuent une réplication entrante sur toutes les partitions Active Directory conservées localement conformément à la planification définie sur les liens de site et les objets de connexion. C’est particulièrement vrai pour le nombre de jours spécifié par l’attribut de durée de vie de la pierre tombstone.

  Si la réplication ne se produit pas, vous pouvez rencontrer un contenu incohérent des bases de données Active Directory sur les contrôleurs de domaine de la forêt. L’incohérence se produit car la connaissance des suppressions persiste pendant le nombre de jours défini par la durée de vie de la pierre tombstone. Lorsque les contrôleurs de domaine ne terminent pas la réplication entrante transitive des modifications d’Active Directory pendant ce nombre de jours, les objets restent dans Active Directory. Le nettoyage des objets persistants peut prendre beaucoup de temps, en particulier dans les forêts multi-domaines qui incluent de nombreux contrôleurs de domaine.

• Pour récupérer après divers problèmes, un contrôleur de domaine Active Directory nécessite des sauvegardes régulières de l’état du système. La durée de vie utile par défaut d’une sauvegarde de l’état du système est de 60 ou 180 jours. Cela dépend de la version du système d’exploitation et de la révision du Service Pack qui est en vigueur pendant l’installation. Cette durée de vie utile est contrôlée par l’attribut de durée de vie tombstone dans Active Directory. Au moins un contrôleur de domaine dans chaque domaine de la forêt doit être sauvegardé sur un cycle normal, selon le nombre de jours spécifié dans la durée de vie de la pierre tombstone.

  Dans un environnement de production, vous devez effectuer des sauvegardes quotidiennes de l’état du système à partir de deux contrôleurs de domaine différents.

  Remarque

  Lorsque l’hôte de machine virtuelle prend une instantané d’une machine virtuelle, le système d’exploitation invité ne détecte pas cette instantané en tant que sauvegarde. Lorsque l’hôte prend en charge l’ID de génération Hyper-V, cet ID est modifié lorsque l’image est démarrée à partir d’un instantané ou d’un réplica. Par défaut, le contrôleur de domaine considère qu’il est restauré à partir d’une sauvegarde.

Éléments à prendre en compte lorsque vous hébergez des rôles de contrôleur de domaine sur des hôtes en cluster ou lorsque vous utilisez Active Directory comme back-end dans un environnement d’hébergement virtuel

• Lorsque vos contrôleurs de domaine s’exécutent sur des serveurs hôtes en cluster, vous vous attendez à ce qu’ils soient tolérants aux pannes. La même attente s’applique aux déploiements de serveurs virtuels qui ne proviennent pas de Microsoft. Toutefois, il existe un problème dans cette hypothèse : pour que les nœuds, disques et autres ressources sur un ordinateur hôte en cluster puissent démarrer automatiquement, les demandes d’authentification de l’ordinateur doivent être traitées par un contrôleur de domaine dans le domaine de l’ordinateur. Une partie de la configuration de l’hôte en cluster doit également être stockée dans Active Directory.

  Pour vous assurer que ces contrôleurs de domaine sont accessibles au démarrage du système de cluster, déployez au moins deux contrôleurs de domaine dans le domaine de l’ordinateur sur une solution d’hébergement indépendante en dehors de ce déploiement de cluster. Vous pouvez utiliser du matériel physique ou une autre solution d’hébergement virtuel qui n’a pas de dépendance Active Directory. Pour plus d’informations sur ce scénario, consultez Éviter de créer des points de défaillance uniques.

• Ces contrôleurs de domaine sur des plateformes distinctes doivent être conservés en ligne et accessibles au réseau (dans DNS et dans tous les ports et protocoles requis) aux hôtes en cluster. Dans certains cas, les seuls contrôleurs de domaine qui peuvent traiter les demandes d’authentification au démarrage du cluster sont sur un ordinateur hôte en cluster en cours de redémarrage. Dans ce cas, les demandes d’authentification échouent et vous devez récupérer manuellement le cluster.

  Remarque

  Ne supposez pas que cette situation s’applique uniquement à Hyper-V. Les solutions de virtualisation tierces peuvent également utiliser Active Directory comme magasin de configuration ou pour l’authentification lors de certaines étapes de démarrage ou de modifications de configuration de la machine virtuelle.

Prise en charge des contrôleurs de domaine Active Directory dans les environnements d’hébergement virtuel

Pour plus d’informations, consultez Stratégie de support pour les logiciels Microsoft qui s’exécutent sur des logiciels de virtualisation matérielle non-Microsoft.