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?

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.

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.

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.

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.

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.

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.