É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 traite également des éléments à prendre en compte lorsqu’un contrôleur de domaine s’exécute dans un environnement d’hébergement virtuel.

Numéro de 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
• Network (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 pour les tests et le développement, et dans les 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 sont les suivants :

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

Pour plus d’informations sur l’état actuel de la robustesse et de la 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 Virtualizing Domain Controllers 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 temps 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 des cœurs de RAM et de processeur sur l’hôte de machine virtuelle.

Cet article complète l’article virtualisation des contrôleurs de domaine en fournissant des conseils et des considérations supplémentaires qui n’étaient pas dans l’étendue de l’article Virtualizing Domain Controllers.

Éléments à prendre en compte lorsque vous hébergez des rôles DC 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 si une perte d’alimentation ou une autre défaillance se produit. Pour ce faire, le service exécute des écritures non sauvegardées et tente de désactiver le cache d’écriture de 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 façon s’il est installé dans un environnement d’hébergement virtuel.

  Si le logiciel d’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 non validées effectuées par Active Directory dans cet environnement sont transmises 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éberge :

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

  Note

  • 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 alimentations non réinterruptables sur des hôtes de machine virtuelle.

• Un contrôleur de domaine Active Directory est destiné à exécuter en continu le mode Active Directory dès son installation. Ne pas arrêter ou suspendre la machine virtuelle pendant une durée prolongée. Au démarrage du contrôleur de domaine, la réplication d’Active Directory doit se produire. Vérifiez que toutes les contrôleurs de domaine effectuent une réplication entrante sur toutes les partitions Active Directory stockées localement en fonction de la planification définie sur les liens de site et les objets de connexion. Il est particulièrement vrai pour le nombre de jours spécifiés par l’attribut de durée de vie de la pierre tombstone.

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

• Pour effectuer une récupération à partir de différents problèmes, un contrôleur de domaine Active Directory nécessite des sauvegardes d’état système régulières. La durée de vie utile par défaut d’une sauvegarde d’état 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 régulier, en fonction du nombre de jours spécifiés dans la durée de vie des pierres tombales.

  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.

  Note

  Lorsque l’hôte de machine virtuelle prend un instantané d’une machine virtuelle, le système d’exploitation invité ne détecte pas cet instantané comme 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 se considère comme étant restauré à partir d’une sauvegarde.

Éléments à prendre en compte lorsque vous hébergez des rôles DC 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 les nœuds, les disques et d’autres ressources sur un ordinateur hôte en cluster pour démarrer automatiquement, les demandes d’authentification de l’ordinateur doivent être utilisées par un contrôleur de domaine dans le domaine de l’ordinateur. Vous pouvez également stocker une partie de la configuration de l’hôte en cluster 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 pendant le démarrage du cluster se trouvent 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.

  Note

  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 pendant certaines étapes de démarrage ou de configuration de machine virtuelle.

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

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