Virtualisation et Active Directory, les choses à faire et à ne pas faire.

Cet article retrace les précos à mettre en place pour virtualiser un environnement Active Directory sous VMware ESX (VI3.X ou vSphere).

Les technologies de virtualisation ont apportés leur lot de fonctionnalités intéressantes en termes de sauvegarde de disque virtuel ou encore de Snapshots de système. Il est cependant fortement déconseillé d’utiliser ces deux fonctionnalités dans la mesure où les services Active Directory sont basés sur un contrôle d’intégrité permanent sur tous les objets de l’annuaire.

L’utilisation de Snapshots, Suspended-state et de non-persistent disks peuvent être la source de corruption Active Directory et d’incohérences de réplication. Pour cette raison, il est nécessaire d’administrer les contrôleurs de domaines avec un rôle défini sur lequel les accès aux fonctionnalités de Snapshots sont désactivés.

Illustration de la définition et de l’assignation d’un rôle sous VMware vSphere

La récupération de données Active Directory en cas de corruption ou d’effacement involontaire d’objets repose sur la sauvegarde d’au moins un contrôleur de domaine par domaine.

Bien que virtualisé, et par conséquent hébergé sur des disques virtuels, il est absolument nécessaire de mettre en place une procédure de sauvegarde et de restauration à l’identique d’un environnement non virtualisé, et de ne surtout pas utiliser les fonctionnalités de Snapshots ou de non-persistent disks pour les raisons mentionnées à la section précédente.

Différence entre la restauration Active Directory par snapshot ou par ntbackup

Pour des raisons de performances accrues, il est nécessaire de placer la base de l’annuaire (NTDS.DIT), les logs et le répertoire SYSVOL sur un disque virtuel SCSI séparé, lui-même stocké sur un disque physique performant et non saturé en IO par d’autres VM.

Afin d’éviter tout goulet d’étranglement réseau dû à l’utilisation simultanée d’une même carte par plusieurs machines virtuelles, il est nécessaire de configurer une carte réseau dédiée pour les DC virtualisés.

Il est de plus conseillé d’utiliser la fonctionnalité MAP View (VMWare) pour se représenter graphiquement la topologie réseau résultante de la configuration des cartes réseaux virtuelles, et potentiellement optimiser la topologie de réplication

Fonctionnalité MAPS View de VMWare

Kerberos est au cœur de toute demande d’authentification Active Directory et exige une synchronisation de l’horloge des clients AD au travers du service de synchronisation du temps. Ce service est transparent et ne nécessite l’utilisation d’une source de temps externe que pour le serveur hébergeant le rôle de PDC Emulator.

Les serveurs hôtes n’étant pas nécessairement clients du domaine hébergé, la synchronisation des machines virtuelles ne doivent pas se faire au travers d’une synchronisation hôte/invité, mais au travers du service de synchronisation du temps AD.

Pour cette raison, il est nécessaire de désactiver l’option de synchronisation de l’horloge système entre hôte et invité. Il est néanmoins tout à fait faisable de synchroniser uniquement le PDC Emulator avec l’hôte en activant l’option.

Dans un environnement mixte (physique et virtuel), il est recommandé de placer les rôles FSMO et les catalogues globaux sur les machines physiques.

Dans un environnement où l’Active Directory est totalement virtualisé, les placements de ces rôles est soumis aux mêmes règles d’architecture que dans un environnement physique.

La KB http://support.microsoft.com/kb/223346 réitère le bon placement des rôles FSMO et les choses à ne pas faire (GC et Maître d’infra sur une même machine dans une environnement multi-domaines par exemple)

Lors de l’utilisation d’un serveur de machines virtuelles hébergeant plusieurs serveurs du même domaine, il est important de définir l’ordre de priorité de démarrage de telle sorte que les Contrôleurs de Domaine aient une priorité plus forte au démarrage.

Illustration de configuration de priorité de démarrage

Le contrôleur de domaine hébergeant le rôle PDC Emulator étant plus sollicité que les autres DC du domaine, il est conseillé de modifier le poids et la priorité de ce serveur au niveau des enregistrements SRV afin de dégager ses ressources pour le rôle FSMO qu’il héberge. Ces modifications peuvent être effectuées dans l’interface de gestion DNS,

ou par clé de registre sur le serveur lui-même en modifiant les clés suivantes :

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters LdapSrvWeight DWORD 50

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters LdapSrvPriority DWORD 200

==> A noter que cette dernière méthode (par clef de registre) ne nécessite pas de redémarrage de la machine afin d’être prise en compte, contrairement à l’intéraction faite en GUI.

Le dimensionnement de la mémoire d’une machine virtuelle doit être pris en compte avec attention. La mécanique VMware associée à une contention au niveau de la RAM s’appuyant sur l’utilisation d’un swap du disque virtuel (De taille égale à la quantité de mémoire fixée pour la VM lors de sa création), la flexibilité qui en résulte détériore dès lors sensiblement les performances générales de la machine virtualisée.

Pour éviter cette constatation de dégradation des performances –qui n’entre en compte que si et uniquement si il n’existe plus assez de ressources mémoires physiques sur l’hôte-, on peut pré-allouer une quantité de mémoire dédiée à la machine virtuelle sous forme de « réservation » mémoire. A partir de ce moment là, et selon l’équation indiquée ci-dessous :

Taille du swap disque = (Taille de la mémoire de la VM) – (Taille de la réservation mémoire de la VM)

le swap disque peut être contenu. Si l’on « réserve » donc la totalité de la mémoire de la VM paramétrée, on indique ainsi que la VM est assurée à tout moment de profiter de la quantité de mémoire ainsi paramétrée, sans aucune possibilité d’utilisation de la technique du swap disque.

Dans ce contexte, il est conseillé de paramétrer –avec parcimonie, car ce paramètre impose une pré-allocation de la mémoire physique de l’hôte auprès du VMKernel et de la VM, et donc, un impact fort sur l’ensemble des machines virtuelles hébergées- la réservation de mémoire sur une machine endossant le rôle d’un contrôleur de domaine.

L’utilisation de plusieurs vCPU pour un contrôleur de domaine n’apporte pas de gain notable, il n’est par conséquent pas nécessaire d’en configurer plus d’un pour ce rôle. De plus, l’overhead engendré par un tel paramétrage des routines du module VMware SMP aurait au final, un aspect plus négatif que positif si l’on devait espérer un gain de performance net. autant éviter doc dans la plupart des cas de figure standard d’une architecture Active directory Multi-maitres et redondée au niveau des contrôleur de domaine.

L’architecture Active Directory est basée sur une réplication et une redondance multi-maitre afin de se préserver de toute interruption de service en cas de panne d’un DC. Il est cependant important de ne pas concevoir d’architecture virtuelle où les uniques contrôleurs de domaine d’un même domaine soient hébergés par le même hôte, annulant alors les avantages de la redondance apportés par les mécanismes Active Directory.

Il ne faut pas effectuer d’opération de conversion de machines physiques vers des machines virtuelles concernant un Active Directory, et encore moins concernant une machine endossant le rôle de contrôleur de domaine. D’une part ça n’est pas supporté, d’autre part, on constatera ici et là des problèmes de corruption de données de la base NTD

Merci à Nelite pour leur contribution