pascals.blog

Pascal Sauliere | Microsoft France | Infrastructure, sécurité, cloud, et plus si affinités

Synchronisation des horloges dans un environnement virtualisé

Synchronisation des horloges dans un environnement virtualisé

  • Comments 6
  • Likes

Dans un environnement de domaine Windows, la synchronisation des horloges des différents systèmes est primordiale, notamment pour que le protocole d’authentification Kerberos fonctionne. Il y a d’autres effets de bord sur certaines applications qui peuvent donner des erreurs difficiles à diagnostiquer si des systèmes ne sont pas synchronisés entre eux, ou ne sont pas à l’heure exacte. Les environnements de type cloud hybride, en particulier, nécessitent que l’heure des systèmes locaux soient correcte vis-à-vis des systèmes dans le cloud public comme Windows Azure.

Dans un environnement virtualisé nous avons deux phénomènes qui cohabitent. En premier lieu, il existe une hiérarchie de synchronisation dans le domaine, selon laquelle le PDC Emulator se synchronise avec une source NTP externe (par défaut time.windows.com), les autres DC se synchronisent sur celui-ci, et les membres se synchronisent sur le DC auquel ils sont connectés. Cela se traduit par le fait que le PDC Emulator a un client de synchronisation dans le mode NTP sur time.windows.com, et les autres systèmes du domaine sont dans le mode NT5DS. On peut voir la configuration du client de synchronisation avec la commande w32tm.exe /query /configuration, ou son statut détaillé avec la commande w32tm.exe /query /status.

Plus précisément, on peut utiliser la commande w32tm.exe /query /source pour afficher la source client de synchronisation. Par exemple, sur le PDC Emulator de la racine de la forêt (à condition que ce soit une machine physique ou que la synchronisation Hyper-V soit désactivée, voir plus loin), la source est bien une source externe :

image

Sur une machine physique membre du domaine, par exemple un hôte Hyper-V, la source est bien un contrôleur de domaine :

image

La hiérarchie de synchronisation des machines dans une forêt Active Directory est représentée dans ce schéma, tiré de cet article de Technet :

Time Synchronization in Active Directory Hierarchy

Comme on peut le voir, le seul système qui se synchronise par défaut sur une source externe est le PDC Emulator du domaine racine de la forêt. Dans le cas où l’on a un seul domaine, c’est le PDC Emulator du domaine.

Avec la virtualisation, un second phénomène s’ajoute. Les machines virtuelles contiennent les services d’intégration Hyper-V et une fonction de ceux-ci consiste à synchroniser l’horloge de la VM avec celle de l’hôte Hyper-V. Cette synchronisation est activée par défaut et peut être désactivée dans les propriétés de la machine virtuelle :

image

Sur une machine virtuelle, quel que soit son rôle (membre,contrôleur de domaine…), la source est donc par défaut le service de synchronisation des Integration Services d’Hyper-V :

image

(VM IC = Virtual Machine Integration Components –autre nom des Integration Services)

Le problème qui se pose alors est celui-ci : si les contrôleurs de domaine (dont le PDC Emulator) sont virtualisés et que les hôtes Hyper-V appartiennent au domaine, nous avons potentiellement un problème de boucle : un DC se synchronise sur son hôte Hyper-V, qui se synchronise lui-même sur ce DC. Au final j’ai pu constater des retards importants dans l’heure d’une plateforme de test.

Prenons l’exemple d’une plateforme de test constituée de quelques Hyper-V membres d’un domaine, quelques VM également membres du domaine, et un seul contrôleur de domaine dans une VM. Deux solutions sont possibles.

La première consisterait à paramétrer le serveur Hyper-V hébergeant le DC à se synchroniser en NTP sur une source externe, au lieu de se synchroniser sur le DC qu’il héberge. En laissant faire la synchronisation Hyper-V sur le DC, celui-ci serait à l’heure de la source externe, les autres serveurs Hyper-V se synchroniserait sur le DC et les autres VM sur leurs serveurs Hyper-V respectifs. Cette solution ne consisterait donc qu’à paramétrer d’un serveur Hyper-V. Mais, en cas de live migration du DC vers un autre serveur Hyper-V, il serait nécessaire de paramétrer également cet autre serveur.

La seconde solution (proposée également dans cet article de Ben Armstrong) consiste à paramétrer le DC lui-même de façon à ce qu’il se synchronise sur une source externe. Mais ce paramétrage doit se faire sur le DC lui-même, et non pas sur les propriétés de sa VM en désactivant la synchronisation Hyper-V, car cela supprimerait la mise à l’heure de la VM lors de son démarrage et son réveil après suspension.

Pour la deuxième solution, le paramétrage du DC pour une synchronisation sur une source externe se fait de la manière suivante.

Dans une ligne de commande administrateur dans la VM du DC :

  • Désactiver la synchronisation vis-à-vis du serveur Hyper-V (cela n’affecte pas la mise à l’heure lors du démarrage ou le réveil de la VM) :
    reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0
  • Configurer le DC pour se synchroniser sur une source externe (ici time.windows.com) :
    w32tm /config /manualpeerlist:time.windows.com /syncfromflags:MANUAL /update
  • Redémarrer le service et forcer une synchronisation immédiate :
    net stop w32time & net start w32time
    w32tm /resync /force
  • Vérifier la source de synchronisation :
    w32tm /query /source

Ce qui donne, sur le DC :

image

Surtout, il est fortement recommandé de ne pas désactiver la synchronisation au niveau des propriétés de la machine virtuelle, cela aurait pour effet de provoquer un retard d’horloge important au réveil de la VM du DC, puisqu’il se “réveillerait” à la même heure que le moment où il aurait été suspendu.

Il y aurait certes une troisième solution plus “basique” qui consisterait à conserver le PDC Emulator sur une machine physique. Mais ce n’est pas l’approche que j’ai choisie. Dans mon cas, ma plateforme de test est à nouveau à l’heure exacte depuis que j’ai mis en oeuvre la solution recommandée ci-dessus.

Pour plus d’informations sur le fonctionnement du service de temps de Windows :

Vous pouvez tester tout ceci aujourd’hui gratuitement en téléchargeant la version Preview de Windows Server 2012 R2 :

Vous pouvez également nous retrouver dès la rentrée pour nos IT Camps près de chez vous :

Comments
  • J'ai testé la seconde solution dans mon environnment cela ne fonctionne pas. La source de temps reste Local CMOS Clock malgré la clé de Registre bien renseigner. Et la dérive temporelle continue

  • C'est sur la VM du DC (PDC Emulator) qu'il faut executer les commandes indiquées, pour qu'il se synchronise sur une source extérieure (time.windows.com dans mon exemple.)

  • Bonsoir,

    Vérifie avec la commande W32TM /resync et netstat -an que tu as bien une sortie réussit. Bien regarder ta règle de dans le FW , qui laisse ton PDC llibre en UDP 123 en sortie.

    Bonne soirée.

  • Super et merci pour ces infos claires!

  • Super et merci pour ces infos claires!

  • Bonjour,
    Est ce que sur la VM controleur de domaine la synchro heure/date des services d’intégration Hyper-V doit etre activée ?
    Merci pour ce tutoriel :)

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment