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


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?


34
2018-04-26 05:29


origine




Réponses:


Sécurité

En général, les horodatages sont utilisés dans divers protocoles d’authentification pour aider à prévenir rejouer les attaques, où un attaquant peut 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 du client et du serveur, l'authentification ne serait pas possible. (Cette restriction est supprimée dans les dernières versions de MIT Kerberos. Le demandeur et le KDC déterminent le décalage entre leurs horloges lors de l'authentification. Toutefois, ces modifications sont survenues après Windows Server 2012 R2 et il faudra un certain temps avant de le voir dans Windows. Certaines implémentations de 2FA nécessiteront probablement toujours des horloges synchronisées.)

Administration

La synchronisation d'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.


52
2018-04-26 05:45



+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
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 vérifie simplement 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
make est également dérouté par 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


C'est principalement pour que vous puissiez corréler les incidents à partir de journaux sur 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.


16
2018-04-26 05:41



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


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 manière dont la solution est conçue, 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 s'effectue par exemple sur un serveur VMWare ESXi 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 qu'il est généralement possible de garder les serveurs du centre de données avec un décalage de moins d'une seconde les uns des autres.


6
2018-04-26 11:40





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 "frottis" et à fractionner le changement sur une période donnée, l'ensemble du processus étant géré par un serveur NTP. Ils publié un blog à ce sujet en 2011, en fait une lecture intéressante et semble pertinente pour cette question.


5
2018-04-27 10:23



Cela ressemble beaucoup à certains clients NTP tué comportement, qui a été implémenté comme pour toujours. - α CVn
@ MichaelKjörling genre de. La différence réside dans le fait que le balayage est destiné à é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


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.


5
2018-04-27 14:16





Je suis d'accord avec tout le point ci-dessus. Je veux lancer plus de pensées
Certaines bases de données telles que Cassendra compte 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.


3
2018-04-27 19:54



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 déroutent 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