J'ai environ 20 serveurs Linux dans un petit réseau et j'ai besoin que leurs horloges soient assez proches les unes des autres (par exemple à moins de 20 ms). J'ai commencé avec chacun d'eux synchronisé avec europe.pool.ntp.org et le travail est terminé.
Maintenant, j'ai deux questions:
- Suis-je un fardeau notable pour la piscine? Est-ce que cela fait une différence notable pour le pool si je frappe depuis 20 serveurs ou depuis 2?
- Si cela fait une différence, quelle est la configuration / configuration qui gardera mon sous-réseau synchronisé et la piscine sous une charge légère? Il existe des directives pour les grands réseaux ( http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101 ) mais je n'en ai trouvé aucune pour les petits réseaux.
peer
relation. Voir par exemple ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101Réponses:
Étant donné que le pool a constamment besoin de serveurs pendant de nombreuses années (voir [1]), je dirais que même si 2 ou 20 serveurs ne font pas vraiment de différence, vous devez toujours vous rappeler que vous n'êtes pas seul. Donc, vous feriez mieux de penser à dire 1000 administrateurs, auquel cas nous parlons de 2000 ou 20000 serveurs et cela fait une différence.
Vous devez synchroniser deux [2] serveurs de votre réseau avec le pool (appelons-les serveurs NTP principaux ), puis synchroniser tous les autres serveurs avec ces deux. Cette méthode a également l'avantage que le temps entre tous vos serveurs sera plus proche (en moins de 1 ms). Ceci est conforme aux meilleures pratiques de l'IETF .
1) La configuration des serveurs NTP principaux
Remplacez les lignes
server
etrestrict
de votre ntp [d] .conf par ce qui suit et conservez le reste à vos valeurs par défaut de distribution [3]:Veuillez noter que cette configuration permet également aux hôtes de partout sur Internet d'interroger l'heure de votre hôte via des requêtes NTP. Utilisez votre pare - feu si vous ne le souhaitez pas. Dans mon exemple, 10.11.12.1 et 10.11.12.2 sont les adresses IP des serveurs NTP principaux (ils ont deux cartes réseau, l'une face à Internet public et l'autre au sous-réseau 10.11.12.x local). Chaque serveur NTP principal a l'autre déclaré comme homologue (homologue signifie à la fois serveur et client - vous utilisez l'autre hôte comme source de temps et l'autre hôte vous utilise également comme source de temps). Ajustez donc l'IP sur la 1ère ligne pour que la configuration de chaque serveur NTP principal pointe vers l' autre en tant que pair. Voir [4] concernant mon choix d'utiliser 4 serveurs.
2) La configuration de tous les autres serveurs
2A) Si vous avez deux interfaces réseau
Vous feriez mieux d'utiliser la 2ème interface pour créer un sous-réseau local (par exemple
10.11.12.0/24
) et l'utiliser pour les requêtes NTP. Dans ce cas, les lignes de restriction peuvent être plus serrées. Remplacez à nouveau les lignesserver
etrestrict
de votre ntp [d] .conf par ce qui suit et conservez le reste à vos valeurs par défaut de distribution [3]:2B) Si vous n'avez pas deux interfaces réseau
Vous devez utiliser les lignes de restriction ci-dessous (et lire la note sur l'utilisation de votre pare-feu pour bloquer l'accès à vos serveurs NTP ci-dessus). Remplacez à nouveau les lignes
server
etrestrict
de votre ntp [d] .conf par ce qui suit et conservez le reste à vos valeurs par défaut de distribution [3]:Remarques
[1] De 2006 à 2012, ils demandent constamment plus de serveurs à rejoindre: la demande de 2006 , celle de 2009 et celle de 2012 . Consultez www.pool.ntp.org pour les mises à jour sur l'état actuel.
[2] Deux serveurs NTP principaux sont uniquement suggérés comme un moyen simple d'avoir une redondance sans arrangements compliqués de haute disponibilité. Vous pouvez opter pour 3 ou 4 pour d'autres raisons (lire à nouveau les meilleures pratiques de l' IETF )
[3] Dans la pratique et peu importe votre distribution, la seule autre chose que vous devez inclure dans votre configuration ntpd est une ligne définissant un répertoire pour mettre un fichier de dérive et un nom pour lui - par exemple
driftfile /var/lib/ntp/ntp.drift
. J'ai testé ma solution dans CentOS, Debian et Ubuntu. Je suppose que cela fonctionne dans la plupart des autres distributions.[4] J'ai configuré 4 serveurs de pool en suivant les meilleures pratiques . La configuration de plus de 4 serveurs est techniquement acceptée, mais vous augmenterez la charge du pool NTP pour un gain de disponibilité discutable, alors ne le faites pas. Dans les meilleures pratiques, je vois que "à partir de ntp-4.2.6, la directive 'pool' produira" suffisamment "d'associations pour fournir un service de temps robuste", donc si vous utilisez .pool. adresses comme je le fais ici et ntp> = 4.2.6 le nombre exact de lignes de serveur n'a probablement pas d'importance.
Rant Oh! Je déteste NTP (sauf que j'aime que ça marche). La documentation officielle est pleine d'informations obsolètes et ils ont "comment puis-je l'utiliser?" informations mélangées avec des détails scientifiques sur les éléments internes. Et je déteste aussi ce que
restrict 127.0.0.1
signifie vraimentallow everything for 127.0.0.1
Historique des mises à jour
J'ai supprimé l'
iburst
option de la configuration des serveurs NTP locaux car leur convivialité envers le pool est discutable. (voir les commentaires). Les supprimer ne fait qu'ajouter quelques minutes de temps d'attente à la première synchronisation.Crédits
Les commentaires et réponses des utilisateurs SF Marki et Sven ont fourni un bon point de départ pour cette réponse. Merci à tous les deux.
la source
iburst
s'agit d'un paramètre ennuyeux à utiliser sur les serveurs publics, alors ne le faites pas (même si ce n'est pas aussi ennuyeux queburst
). Les administrateurs de serveurs de pool vous rendent service sans savoir qui vous êtes et sans aucune récompense pour eux-mêmes, uniquement pour le meilleur fonctionnement d'Internet. Si vous, en travaillant plus dur, pouvez leur faciliter la vie, vous leur devez de le faire.burst
, maisiburst
dit même (à partir de lantpd
page de manuel) " avec cette option, une volée de messages est échangée pour nettoyer les données et régler l'horloge dans environ 10 secondes ". Utiliseriburst
dit " régler rapidement mon horloge est plus important que de maintenir une charge faible sur votre serveur ", et c'est impoli.iburst
est beaucoup moins répréhensible queburst
. Mon point est que lorsque vous utilisez gratuitement les ressources de quelqu'un d'autre, il y a un argument selon lequel vous devriez vous pencher en arrière pour être prévenant; le simple fait de ne pas être activement inconsidéré peut ne pas suffire. Je suis d'accord pour dire qu'il s'agit de la meilleure pratique, mais ces documents ne tiennent pas compte du fait que les serveurs en amont auxquels vous vous synchronisez font partie de votre entreprise ou non; ils dictent les meilleures pratiques techniques (qui, je suis d'accord, à utiliseriburst
) plutôt que les meilleures pratiques sociales .L'approche habituelle consiste à utiliser une configuration à plusieurs niveaux - vous synchronisez un ou deux serveurs de votre réseau avec le pool, puis vous les utilisez comme source d'heure locale. Ces niveaux sont appelés strates dans le jargon NTP.
Pensez-y également: si vous faites cela comme vous l'avez décrit, ce ne sera pas vraiment perceptible, mais si 1000 sites de votre taille démarrent cela, vous vous retrouvez avec 20k demandes pour la plupart inutiles et à un moment donné, cela devient perceptible.
Lisez http://en.wikipedia.org/wiki/Network_Time_Protocol
la source
pool.ntp.org
. Certes, le trafic DNS dépasse le trafic NTP. Devez-vous également mettre en cache DNS localement? Même le trafic DNS est susceptible d'être minuscule par rapport au reste de votre consommation de bande passante.ntp.pool.org
ils violent les conditions du pool ; s'ils l'ont fait correctement en postulant pour une zone de fournisseur (voir lien), ils devront également contribuer au projet de pool proportionnellement à leur charge (encore une fois, voir lien).