Question Configuration de serveurs NTP


J'ai un problème pour configurer NTP afin de conserver l'heure sur un réseau autonome. Ce sera un fuseau horaire de l'île. Le problème est que le temps s'écoule, même après la synchronisation initiale.

Il existe deux serveurs NTP redondants exécutant RHEL 5.4 et plusieurs clients Windows XP. La condition requise est que le réseau se synchronise sur le serveur A tandis que le serveur B joue le rôle de sauvegarde. Nous avons un GPS qui agit comme un serveur de temps contrôlant à la fois les serveurs A et B, mais il n’est pas toujours disponible. Lorsque le GPS est présent, les deux serveurs se synchronisent sur le GPS.

Les clients XP semblent se diviser en deux groupes une fois les serveurs séparés. avec certains serveurs suivants A et d’autres serveur B.

Comment puis-je empêcher mes deux serveurs de se séparer?

Puis-je contrôler quel serveur les clients XP suivent?

Les deux fichiers ntp.conf sont les suivants

ntp.conf pour le serveur A (10.203.224.13)

# Tweek NTP's behavior
tinker panic 0 step 0.01 stepout 64

# GPS
server 10.203.220.12 burst iburst minpoll 4 maxpoll 6

# Server A
server 10.203.224.13 burst iburst minpoll 4 maxpoll 6

# Server B
server 10.203.224.14 burst iburst minpoll 4 maxpoll 6

# Configure the local clock to serve from
server 127.127.1.1
fudge 127.127.1.1 stratum 11

# Establish the drift file location
driftfile /etc/ntp.drift 

ntp.conf pour le serveur B (10.203.224.14)

# Tweek NTP's behavior
tinker panic 0 step 0.01 stepout 64

# GPS
server 10.203.220.12 burst iburst minpoll 4 maxpoll 6

# Server A
server 10.203.224.13 burst iburst minpoll 4 maxpoll 6

# Server B
server 10.203.224.14 burst iburst minpoll 4 maxpoll 6

# Configure the local clock to serve from
server 127.127.1.1
fudge 127.127.1.1 stratum 13

# Establish the drift file location
driftfile /etc/ntp.drift

Sur le serveur A

[root@serverA]# ntpq -p

     remote           refid          st t when poll reach   delay   offset  jitter
==============================================================================
 10.203.220.12   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.203.224.13   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.203.224.14   LOCAL(1)        14 u   27   64  377    0.312  359.753   0.289
*LOCAL(1)       .LOCL.          11 l   55   64  377    0.000    0.000   0.001

Sur le serveur B

[root@serverB]# ntpq -p

     remote           refid          st t when poll reach   delay   offset  jitter
==============================================================================
 10.203.220.12   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.203.224.13   LOCAL(1)        12 u   55   64  377    0.346  -359.56   0.107
 10.203.224.14   .INIT.          16 u    -   64    0    0.000    0.000   0.000
*LOCAL(1)       .LOCL.          13 l   54   64  377    0.000    0.000   0.001

5
2017-11-13 11:53


origine




Réponses:


Sur le serveur A, supprimez les lignes pointant sur lui-même et sur le serveur B, en ne laissant que la ligne d'horloge locale "fudge" et le GPS. Sur le serveur B, supprimez la ligne "fudge" et la ligne du serveur B, ne laissant que la ligne du serveur A et le GPS.

L'idée est que le serveur A devrait utiliser le GPS s'il est disponible, sinon il devrait faire confiance à sa propre horloge. Le serveur B doit utiliser le serveur A, peu importe la façon dont le serveur A reçoit l'heure ou le GPS. Si le serveur B est autorisé à se faire confiance, il annoncera une source de temps fiable auprès de ses clients, même si cette heure est différente de celle du serveur A - ce que vous voyez.


4
2017-11-13 12:27



Merci MadHatta. Le serveur B pourra-t-il toujours envoyer son heure si le serveur A est hors ligne? - DanS
Oui, à condition que le GPS soit en ligne; mais si ni est disponible, ce ne sera pas. Si vous le souhaitez, vous avez un problème. vous avez demandé deux sources d'horloge indépendantes qui ne dérivent pas l'une par rapport à l'autre, ce qui nécessite un meilleur matériel que les horloges de la carte mère. - MadHatter
Pas vraiment une situation idéale, mais comme un cas d'échec. Nous devons nous assurer que les clients WinXP suivent le serveur disponible. - DanS
Et si vous aviez construit une situation avec un seul serveur disponible à la fois, ce ne serait pas un problème. Votre problème est que vous pouvez parfois avoir deux serveurs disponibles, puis vous êtes surpris que certains clients les suivent. - MadHatter
Le peut tos orphan Dans ce cas, la commande doit être utilisée pour que le serveur B puisse servir sa propre heure (inexacte) mais seulement s’il n’ya pas de meilleure option? - DanS


Il y a un certain nombre de problèmes ici:

  1. Le périphérique GPS ne fonctionne pas correctement. C'est probablement un problème de connectivité. Soit un pare-feu bloque les paquets, soit il n’écoute pas l’interface correcte, soit il ne peut pas atteindre un signal GPS ou quelque chose de similaire. Ce pourrait être cette indisponibilité intermittente que vous avez mentionnée. Si oui, essayez de montrer un ntpq -p à partir de quand ça marche.
  2. Le GPS est la couche 16. Quand il fonctionne, cela devrait être 1. Tout ce qui est plus haut que 11 causera le même problème que vous, car le serveur A fera plus confiance à son horloge locale qu'à 11 ou plus.
  3. Le serveur A est configuré pour obtenir l'heure du serveur B et le serveur B est configuré pour obtenir l'heure du serveur A. Ce type d'installation doit être une relation d'appairage plutôt qu'une relation circulaire maître / esclave. Utilisez le peer mot-clé plutôt que le server mot-clé pour cela.
  4. Les serveurs A et B sont tous deux configurés pour s'utiliser eux-mêmes comme source de temps via le protocole ntp. Ceci est redondant et ne fonctionne pas. Soit la connexion est défaillante, soit la strate actuelle est 16 et ne peut aller plus haut.
  5. Les deux serveurs ont sélectionné leurs propres horloges comme source de temps la plus fiable (indiquée par le signe * à côté de la LOCAL la source. Ils ont également tous deux réussi à se connecter. Je ne sais pas pourquoi le serveur B n’a pas choisi le serveur A comme meilleure source de temps car il a la valeur de strate la plus basse, mais c’est probablement parce qu’il a une gigue nettement plus élevée que la LOCALsource de temps.

Faites fonctionner le GPS, modifiez les deux serveurs pour qu'ils se croisent et supprimez les lignes pour obtenir l'heure de leur propre adresse IP. (L'horloge locale convient, mais il est stupide d'ajouter la latence d'un protocole réseau pour une horloge locale.)


4
2017-11-13 12:41