Virtualiser ses contrôleurs de domaine

Cela faisait un certain temps que je souhaitais publier un billet sur le sujet, ce sera maintenant chose faite.

On entend beaucoup de choses sur la virtualisation des DCs, toutes ne sont pas vraies, toutes ne sont pas fausses.

Tout d’abord, partons des recommandations officielles : (je vous encourage à les lire, en entier)

• Considerations when hosting Active Directory domain controller in virtual hosting environments
• Running Domain Controllers in Hyper-V
• Running Domain Controllers in Virtual Server 2005

Je vous recommande également la lecture du billet de l’équipe support Domaine & Sécurité France :

• DC Virtuel: Les règles de bases

Je rajouterais un point qui me parait des plus importants ! Dans certaines documentations, il est recommandé de conserver un contrôleur physique, et ce, pour éviter qu’un souci qui toucherais l’hyperviseur (quel qu’il soit) impacte l’ensemble de votre production.

Je suis tout à fait d’accord avec cette recommandation, mais également pour d’autres raisons, avec éventuellement une autre solution. Prenons 2 cas.

Un cluster Hyper-V : Imaginons que votre DC est virtualisé au sein d’un cluster Hyper-V. Le cluster tombe pour une raison X ou Y. Lors du redémarrage des nœuds, ceux ci vont chercher à contacter l’AD avant de monter les ressources (c’est à dire l’AD). Vous voyez arriver le problème ? Le serpent se mord la queue. Ainsi, même si vous ne souhaitez pas conserver un contrôleur physique, je vous conseille de virtualiser vos DCs sur 2 plateformes différentes (par exemple 2 cluster indépendants, ou encore 1 cluster Hyper-V , et un serveur “standalone”).

Une version d’essai d’un autre hyperviseur : La aussi, imaginons un hyperviseur autre que Hyper-V. Imaginons que ceux-ci fournissent une mise à jour, qui fait expirer les licences de la version précédente. Imaginons encore que cela provoque l’impossibilité de démarrer les hyperviseurs… Et enfin imaginons que tous vos DCs se trouvent sur cette plateforme… Vous me direz, cela fait beaucoup d’”imaginons”… et pourtant…Enfin, imaginons que le workaround de l’éditeur est de changer la date sur les hyperviseurs pour pouvoir démarrer, et que vous avez une synchro horaire entre les hôtes et les invités… (un fix est sorti rapidement pour corriger le timebomb…)

Bref, vous le constatez, il est possible de se retrouver assez rapidement dans une situation difficile.

Donc, pour résumer:

• Vérifier la supportabilité de l’hyperviseur et de l’OS du DC
• Sécuriser l’hôte comme s’il s’agissait du DC lui-même (il en va de même pour les VHD)
• Désactiver la synchronisation de temps hôte/invité
• Réaliser de vraies sauvegardes ! et pas une copie de VHD !
• Réaliser de vraies restaurations ! et pas une restauration de VHD !
• Ne pas réaliser de snapshot sur le DC
• Ne pas utiliser la fonction “pause”, ni la fonction “savestate”
• Ne pas cloner un DC
• Ne pas utiliser la fonctionnalité d’export de VM avec un DC.
• Et enfin, conserver un DC physique, ou héberger plusieurs DCs sur des plateformes virtuelles différentes (2 clusters, 2 serveurs standalone, ou un mix)

J’espère que cela vous aidera à monter vos infrastructures virtuelles au mieux. Si vous souhaitez en discuter et que vous êtes partenaire Microsoft, n’hésitez pas à nous contacter, vous trouverez les infos ici : http://blogs.technet.com/ptcfr/archive/2010/01/05/vous-aider.aspx

A très bientôt pour de plus amples précisions.

~ par jpk le 5 janvier 2010.