Pourquoi est-il important que les serveurs aient exactement le même temps?


35

J'ai lu à plusieurs reprises (même si je ne le trouve pas pour le moment) que les centres de données déploient beaucoup d'efforts pour s'assurer que tous les serveurs ont exactement la même heure. Y compris, mais sans s'y limiter, se soucier des secondes intercalaires.

Pourquoi est-il si important que les serveurs aient le même temps? Et quelles sont les tolérances réelles?

Réponses:


53

Sécurité

En général, les horodatages sont utilisés dans divers protocoles d'authentification afin d'empêcher les attaques par rejeu . Un attaquant peut alors réutiliser un jeton d'authentification qu'il a pu voler (par exemple, en reniflant le réseau).

L'authentification Kerberos fait exactement cela, par exemple. Dans la version de Kerberos utilisée dans Windows, la tolérance par défaut est de 5 minutes.

Ceci est également utilisé par divers protocoles de mot de passe à usage unique utilisés pour l'authentification à deux facteurs, tels que Google Authenticator, RSA SecurID, etc. Dans ces cas, la tolérance est généralement comprise entre 30 et 60 secondes.

Sans la synchronisation entre le client et le serveur, l'authentification ne serait pas possible. (Cette restriction est supprimée dans les versions les plus récentes de MIT Kerberos. Le demandeur et le KDC déterminent le décalage entre leurs horloges lors de l'authentification. Toutefois, ces modifications ont eu lieu après Windows Server 2012 R2. Certaines implémentations de 2FA nécessiteront probablement toujours des horloges synchronisées.)

Administration

La synchronisation des horloges facilite le travail avec des systèmes disparates. Par exemple, la corrélation des entrées de journal de plusieurs serveurs est beaucoup plus facile si tous les systèmes ont la même heure. Dans ces cas, vous pouvez généralement travailler avec une tolérance de 1 seconde, ce que NTP fournira, mais vous souhaitez idéalement que les heures soient aussi synchronisées que possible. PTP, qui offre des tolérances beaucoup plus strictes, peut être beaucoup plus coûteux à mettre en œuvre.


16
+1 Dépannage des conditions d'erreur sur les systèmes distribués avec des horodatages de journalisation désynchronisés: plus jamais
Mathias R. Jessen

3
Les serveurs exécutant un démon NTP sont généralement synchronisés en moins de 0,01 seconde (quelques millisecondes). La synchronisation NTP Windows native ne vérifie que quelques fois par jour et n'est pas aussi précise. Il existe des clients NTP disponibles pour Windows offrant une bonne synchronisation.
BillThor

+1 pour cette réponse, parce que je viens de vérifier l'heure de mon système et que j'avais 5 secondes de retard, mais maintenant j'utilise ntp pour synchroniser, il serait bon d'ajouter à la question un lien vers ntp.org afin que les gens puissent consulter leur système
Freedo

2
makeconfond également avec les décalages d’horloge entre NFS client / serveur.
Sobrique

@ BillThor, vos informations sur le service de temps Windows ont environ 10 ans de retard. Il s'agit d'un client NTP complet depuis la publication de 2003R2 et synchronise de manière adaptative une partie de l'agent d'un domaine AD. Nous voyons des décalages typiques <16 ms sur 2008R2 des limites du tick du système 64Hz. Nous constatons un meilleur chronométrage sur les boîtes de 2012+ qui peuvent utiliser des intervalles de ticks plus petits.
rmalayter

17

C'est principalement pour que vous puissiez corréler les incidents à partir des journaux de différents périphériques. Supposons qu'un incident de sécurité survienne lorsqu'un utilisateur accède à votre base de données via votre serveur Web. Vous souhaitez que les horodatages de votre pare-feu, de votre équilibreur de charge, de votre serveur Web et de votre serveur de base de données correspondent, afin que vous puissiez trouver les journaux sur chaque périphérique. qui se rapportent à l'incident. Idéalement, vous aimeriez que tout soit en quelques millisecondes. De plus, il doit être synchronisé avec l'heure externe réelle, afin que vous puissiez également corréler vos journaux avec des journaux tiers, si cela s'avérait nécessaire.


2
En outre, certaines solutions de sécurité telles que LDAP et / ou Kerberos échoueront si le temps n’est pas synchronisé. De même que certaines solutions de haute disponibilité.
Jenny D dit: Réintégrer Monica le

7

Non seulement cela est important du point de vue de l'administration, mais la synchronisation des horloges est également importante du point de vue de la corrélation au niveau de l'application. Cela dépend de la conception de la solution et de la façon dont les applications en cours d'exécution obtiennent leur horodatage pour toutes les transactions avec lesquelles elles peuvent travailler. J'ai constaté que la validation des transactions échouait à cause d'une application exécutée sur un serveur avec un décalage trop important (environ 20 secondes à l'avenir) par rapport aux autres applications avec lesquelles elle interagissait.

De même, si la virtualisation est effectuée sur un serveur VMWare ESXi, par exemple, et que l'heure de la machine virtuelle n'est pas synchronisée avec celle de l'hyperviseur, une action telle que vmotion peut resynchroniser l'horloge de la machine virtuelle avec les hyperviseurs, ce qui peut entraîner des résultats imprévisibles. si le décalage horaire est suffisant.

Je ne sais pas quelles sont les tolérances réelles, car je pense que cela dépend beaucoup du type de système, mais je pense que, d'une manière générale, il est possible de garder les serveurs du centre de données avec un décalage de moins d'une seconde les uns des autres.


6

Comme vous avez mentionné les secondes intercalaires, il convient de noter qu’elles nécessitent une manipulation particulièrement difficile.

Ils sont généralement ajoutés en injectant une seconde sous la forme 23:59:60, ce qui est problématique si vous validez les horodatages entre 0 et 59 pour les champs des minutes et des secondes. L'alternative consistant à répéter 23:59:59 pour faire 2 secondes n'est pas meilleure, car cela gâchera tout ce qui est sensible au chronométrage jusqu'à un niveau par seconde.

En fait, Google a mis au point une bonne solution il y a quelque temps qui ne semble pas encore avoir été largement adoptée. Leur solution consistait à appliquer un saut graduel et à fractionner le changement sur une période donnée, l'ensemble du processus étant géré par un serveur NTP. Ils ont publié un blog à ce sujet en 2011, ce qui en fait une lecture intéressante et semble pertinent pour cette question.


Cela ressemble beaucoup au comportement de balayage de certains clients NTP , qui a été implémenté comme jamais.
un CVn

@ MichaelKjörling genre de. La différence réside dans le fait que le balayage est conçu pour éviter les sauts importants après la détermination de l’horloge en corrigeant dans le temps. Ce que Google a fait, c’est d’ajouter intentionnellement un décalage à son serveur ntp, tournant à l’avance et n’ayant ainsi jamais la seconde intercalaire.
Kaithar le

5

Chaque fois que des horodatages sont impliqués, les périphériques désynchronisés peuvent créer des incohérences logiques, telles que: A envoie une requête à B, et la réponse de B reçoit un horodatage antérieur à celui de la requête, ce qui peut éventuellement l’ignorer.


4

Je suis d'accord avec tout le point ci-dessus. Je veux lancer plus de réflexions
Certaines bases de données telles que Cassendra reposent beaucoup sur l'horodatage . C'est la façon dont il traite avec la concurrence.

Un horodatage différent perturbera complètement la base de données.


2
C'est mieux posté comme un commentaire
Dave M

J'ai donc mis à niveau la glibc sur un ensemble de machines CentOS 5.2 et la mise à jour a accidentellement défini la moitié du fuseau horaire MST; nous avons immédiatement rencontré des problèmes avec le fait que des utilisateurs soient déconnectés de manière aléatoire en raison d'une "inactivité". Toutes sortes de petits widgets et dodings s'attendent à ce que le temps soit plus ou moins correct. De plus, si votre temps est mauvais et que votre auto-corrigé revient, vous vous retrouvez avec des fichiers et enregistrez des horodatages qui sont vraiment déroutants et viennent du futur ...
Some Linux Nerd

Je m'attendrais à ce que cela soit vrai pour beaucoup de bases de données distribuées. Une différence d'horodatage de quelques secondes seulement peut suffire à inverser l'ordre des deux opérations.
Kaithar
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.