Virtualisation de DC : recommandations et bonnes pratiques

  • Article

Hi

Voici un article de Christophe Guerre, PFE Active Directory, Azure et AD dans Azure.

Cet article a pour but de regrouper les principales recommandations sur la virtualisation d’un contrôleur de domaine afin d’en tirer les meilleures performances, plutôt orienté Hyper-v mais certaines recommandations sont aussi valables pour d’autres hyperviseurs.

Ce post est dédié à la virtualisation d’un DC dans un cloud On Premise, un deuxième post sera dédié aux spécifications de virtualisation d’un DC dans un cloud public

Commençons par les basiques de la virtualisation d’un contrôleur de domaine

https://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(v=ws.10).aspx#operational_considerations_for_virtualized_domain_controllers

  • Ne pas utiliser la fonction pause ou save
  • Ne pas faire un Power Off sauf si contraint (comme une machine physique) et ce même si l’hôte doit être éteint.
    • Vous devez configurer la VM pour qu’elle ne soit pas mise en pause par l’hôte lors de l’arrêt mais éteinte « Shutdown the guest operating system”
  • Ne pas restaurer de Checkpoints (Snapshots) de la machine virtuelle (surtout pour des contrôleurs de domaine inférieur à Windows Server 2012)Ne pas effectuer de conversion P2V (Physical to Virtual) alors que le DC est démarré. Cela pour les mêmes conséquences que la restauration d’un Checkpoint, le plus courant : l’USN roll back ! et ne pas remettre le DC Physique sur le réseau de production.
  • Ne pas effectuer de clone d’un disque dur virtuel d’un contrôleur de domaine quelque soit la version de l’OS. Depuis Windows Server 2012, vous pouvez cloner un contrôleur de domaine mais ce dernier doit être préparé pour que cela soit supporté et fonctionnel.
  • Ne pas exporter la VM
  • Ne pas synchroniser le service de temps de la VM avec l’hôte. Arrêter la VM et décocher Time synchronization dans le menu Integration Services.
  • Lors de la création de la VM, choisir la version de l’OS (ex : Windows Server 2012 R2). Cela peut influer sur le choix des tools et des optimisations.

Maintenant intéressons-nous à la configuration matérielle de la VM

https://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(v=ws.10).aspx#deployment_considerations_for_virtualized_domain_controllers

  • 2 vCPU au minimum, afin de garantir une performance optimale de l’Active Directory pendant que le système traite les autres tâches.
  • 4Go de mémoire au minimum pour la mémoire de démarrage. L’utilisation de la mémoire dynamique est supportée. Ma recommandation sur ce sujet est de mettre la mémoire minimum égale à la mémoire nécessaire pour mettre la base de l’AD en cache afin d'éviter au maximum les entrées sorties disque et ainsi réduire de manière significative les temps de réponse aux requêtes. On peut prendre comme base 3 Go + taille de la base Active Directory à affiner en fonction de l’utilisation du DC.
  • Ne pas mettre de lecteur de DVD. Cela permet d’empêcher l’utilisation d’une ISO, de l’autoplay ou de démarrer dessus. On pourra à la demande en installer un sans redémarrage si celui-ci est en SCSI.
  • Préférer le format vhdx pour les disques virtuels.
  • Séparer le disque système du disque contenant l’Active Directory. Le cache en écriture est désactivé sur le disque contenant les fichiers de l’Active Directory. Dans cette configuration, on peut différencier la configuration du disque système, du disque hébergeant l’AD. 60 Go au minimum pour le disque Système. Pour le disque hébergeant l’AD cela dépend de la taille de votre base et des logs.
  • Afin de garantir la performance et de durabilité (c’est-à-dire éviter la corruption) des fichiers de données relatif à l’Active Directory (ntds.dit, logs et sysvol), vous devez les placer sur un disque virtuel attaché à un contrôleur SCSI. Le contrôleur SCSI permet d’utiliser FUA (Forced Unit Access) permettant à l’OS de bypasser tous mécanismes de cache et ainsi lire et écrire directement depuis le disque.
    • Pour les DCs existants ayant les fichiers de l’Active Directory sur un disque IDE, assurez-vous d’avoir désactivé le cache sur ce disque.
    • Pour Windows Server 2012, appliquer le hotfix KB2855336 pour résoudre le problème.
  • Utiliser de préférence des VM de Génération 2, proposant par défaut un contrôleur disque SCSI et l’UEFI (Secure Boot) ainsi que des disques au format vhdx
  • L’utilisation de disque en Pass-through est l’utilisation préférée mais pas forcément la plus optimale dans un environnement à forte densité (nécessite la présence d’un disque physique ou d’une LUN).
  • Utiliser de préférence des disques ayant la totalité de la taille allouée (Thick Disk)
  • Ne pas utiliser de disque différentiel

Recommandations sur les règles de placement

  • Afin de garantir le maximum de disponibilité pour l’authentification du domaine/Foret, il est nécessaire de mettre les DCs dans des domaines d’upgrades différents. C’est-à-dire que les DCs doivent être sur des hôtes différents (un cluster de préférence), sur des Racks différents, sur des périodes de mise à jour différentes. Pour ce faire, on utilisera la fonctionnalité d’anti-affinité des clusters.
  • Noter qu’il est fortement recommandé de conserver au moins un contrôleur de domaine physique par domaine afin de garantir une authentification même si l’infrastructure virtuelle est en panne. Noter que depuis 2012 il est possible de démarrer un cluster Hyper-V sans que l’Active Directory soit disponible : https://blogs.technet.com/b/wincat/archive/2012/08/29/windows-server-2012-failover-cluster-enhanced-integration-with-active-directory-ad.aspx
  • De manière générale, la VM ne doit pas être placée sur un hôte ayant un système disque fortement utilisé ou ayant des ressources faibles. Vous pouvez utiliser un ressource pool/ Cloud spécifique ou augmenter les métriques de la VM (CPU, Memory Priority), utiliser la QoS pour le réseau ou le System Disk.
  • Je vous recommande de minimiser le déplacement des disques à chaud (Storage Migration) des DCs et de ne pas le faire pour ceux en version inférieure à Windows Server 2012.

Recommandations sur la sauvegarde

  • La sauvegarde d’un DC virtuel ne diffère pas de la sauvegarde d’un DC physique. Il est recommandé de faire une sauvegarde Bare Metal Recovery (BMR, option -allcritical) et non une sauvegarde de l’enveloppe. On préférera une sauvegarde BMR plutôt qu’une sauvegarde System State. Une sauvegarde BMR permettra de restaurer le DC sans devoir réinstaller un OS. Quelque soit la méthode choisie, la génération (ou version) de la VM d’origine doit être respectée ainsi que le nombre de CPU, la taille de la mémoire et la taille des disques.
  • La recommandation actuelle est une sauvegarde d’au moins 2 DCs par domaine (dont 1 virtuel pour une non dépendance au matériel) ou plus précisément 2 DCs par partitions (attention aux partitions applicatives crées).
  • Pour ma part, je mets généralement en place une sauvegarde BMR avec Windows Server Backup sur un disque local dédié (Pour bénéficier de l’historique des sauvegardes) puis sauvegarder ce dernier par avec un outil tiers permettant l’externalisation.
  • Souvent assimilé comme une solution de sauvegarde, la fonctionnalité Hyper-V Replica est supporté pour des DCs virtuels à partir de Windows Server 2012, néanmoins seuls certains scénarios de restauration sont possibles.

Recommandations sur la sécurité

  • Ce point est souvent négligé ou tout simplement non abordé, pourtant la virtualisation d’un DC introduit un nouvel axe de piratage. Il est très facile pour un administrateur du système de stockage ou de l’infrastructure virtuelle de copier ou manipuler le disque virtuel contenant l’AD et ainsi faire une attaque offline ou d’introduire un cheval de Troie.
  • Le DC virtuel doit être considérer comme un DC physique, l’hôte (l’hyperviseur) doit être considéré comme un DC physique. Ce qui implique des considérations particulières pour les Administrateurs gérant l’hôte ou le système de disque. Ils doivent être considérés comme des administrateurs du domaine ou de la forêt. Il en va de même pour les administrateurs du stockage qui ont accès aux disques, voir aux sauvegardes.
  • Pour maximiser la sécurité des DC virtuels, nous avons principalement 3 possibilités :
    • La mise en place de Bitlocker sur les disques physiques de l’hôte contenant ceux de la VM.

Noter que Bitlocker le disque virtuel système n’est pas supporté. Il est possible de Bitlocker le disque virtuel de data hébergeant l’Active Directory mais vous aurez un problème lors du reboot du DC. La partition sera verrouillée donc le service Active Directory ne pourra pas démarrer et aucun moyen de l’automatiser.

    • Dédier les hôtes et le stockage aux DCs virtuels
    • Configurer les DCs Virtuels en RODC si nécessaire. (Il n'y a pas de raison que ce soit systématique).

  • La recommandation la plus simple, est de mettre à jour régulièrement l’OS en utilisant Windows Update ou un serveur WSUS.

  • L’utilisation de serveur en mode Core peut aussi être une bonne pratique. Ils exposent moins de surface d’attaque, sont moins sujets aux mises jour et sont plus rapides au démarrage (surtout dans une VM de génération 2). Néanmoins, l’utilisation du mode Core nécessite une certaine expérience de PowerShell et de l’invite de commandes. Pour concilier les 2 modes on pourra choisir l’installation minimale.

  • Une bonne pratique, qui n’est pas propre aux DCs Virtuels, est de renforcer leurs sécurité en s’inspirant des recommandations de l’outil Security Compliance Manager, en désactivant le stockage des mots de passe ou l’autoplay et le document Best Practices for Securing Active Directory

  • Sécuriser l’accès aux carte ILO de l’hyperviseur

  • Sécuriser l’hyperviseur (hardening). Pour Hyper-V le guide est disponible ici.

  • Et tout simplement restreindre et surveiller l’accès à la machine physique ainsi qu’aux disques.

Recommandations sur la surveillance des DCs Virtuels

En tout point identique aux DCs physiques, on surveille les principaux métriques (la liste suivante n’est pas exhaustive, il est conseillé d’utiliser un outil de monitoring actif) :

Processor Utilization

  • Processor : %Processor Time : _Total
  • Process : %Processor Time : LSASS
  • System\Processor queue length

Memory Utilization

  • Memory : Available Megabytes
  • Memory : Committed Bytes
  • Memory : Pool Paged Bytes
  • Memory : Pool NonPaged Bytes
  • Memory : Pages/Sec

Page File : %Usage Total

Process : Virtual Bytes

Database :

  • Database cache Size (MB) (for lsass)
  • Database cache hit % (for lsass)
  • I/O Database Reads/Sec
  • I/O Database Writes/Sec

Security System-Wide Statistics :

  • Kerberos authentication
  • NTLM authentication

Directory Services :

  • LDAP Searches/Sec
  • AB Client Sessions
  • LDAP Bind Time
  • DRA Pending Replication Operation

Disk Utilization

  • LogicalDisk : Free Megabytes : (All Instances except _Total)
  • LogicalDisk : Disk Sec/read : (All Instances except _Total) – Primarily used for trending or troubleshooting, no defined thresholds.
  • LogicalDisk : Disk Sec/write : (All Instances except _Total) – Primarily used for trending or troubleshooting, no defined thresholds.
  • LogicalDisk : Avg. Disk Sec/Reads : (All Instances except _Total)
  • LogicalDisk : Avg. Disk Sec/Write : (All Instances except _Total)

Network Utilization

  • Network Interface : Output Queue Length : (Appropriate Instances)
  • Network Interface : Outbound Discarded : (Appropriate Instances)
  • Network Interface : Outbound Errors : (Appropriate Instances)
  • Network Interface : Packets Received Discarded : (Appropriate Instances)
  • Network Interface : Packets Received Errors : (Appropriate Instances)
  • Network Interface : Packets Received Unknown : (Appropriate Instances)

Redirector : Errors/Sec

  • Server Service
  • Server : Errors System
  • Server : File Directory Searches
  • Server : Files Open
  • Server : Sessions
  • Server : Sessions Errored Out
  • Server Work Items : Available Work Items : (All Instances)

Référence : Monitoring Performance in Active Directory

A noter qu’il est préférable de prendre en compte les compteurs spécifiques de chaque hyperviseur (des compteurs dédiés existent pour VMWare au niveau de l’OS Guest) et plus généralement les compteurs propres à l’hôte.

Pour vous aider dans la surveillance de ces compteurs vous pouvez utiliser System Center Operation Manager, des outils tiers mais aussi Microsoft Operations Management Suite hébergé dans Azure.

Vous devez aussi surveiller votre hyperviseur afin qu’il garantisse les ressources nécessaires aux DCs. Vous pouvez vous inspirer du document de Tuning de Windows Server 2012 R2 et un futur article présentera les compteurs les plus importants à surveiller.

A suivre ...

Pour conclure, la virtualisation des DC est maintenant une alternative fiable et maîtrisée aux DC physiques coûteux et moins flexibles.

Même s’il y a des précautions à prendre et des limitations, cela ne nous prive pas de la mobilité de la VM, de la facilité de sauvegarde ou de la faculté de modifier la capacité des VMs.

Il ne vous reste plus qu’à vous lancer !

A bientôt :)

Christophe