5 votes

Configuration des serveurs NTP

J'ai un problème pour configurer NTP afin de maintenir l'heure sur un réseau autonome. Il s'agira d'un fuseau horaire insulaire. Le problème est que l'heure dérive, même après avoir été initialement synchronisée.

Il existe deux serveurs NTP redondants fonctionnant sous RHEL 5.4 et plusieurs clients Windows XP. Les exigences sont que le réseau se synchronise sur le serveur A tandis que le serveur B sert de sauvegarde. Nous avons un GPS qui agit comme un serveur de temps contrôlant à la fois le serveur A et le serveur 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 lorsque les serveurs s'éloignent l'un de l'autre ; certains suivent le serveur A et d'autres le serveur B.

Comment puis-je empêcher mes deux serveurs de s'éloigner l'un de l'autre ?

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

4voto

MadHatter Points 77602

Sur le serveur A, supprimez les lignes pointant vers lui-même et le serveur B, 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 doit utiliser le GPS s'il est disponible, sinon il doit faire confiance à sa propre horloge. Le serveur B doit utiliser le serveur A, quelle que soit la manière dont le serveur A obtient l'heure, ou le GPS. Si le serveur B est autorisé à se faire confiance, il annoncera une source de temps fiable à ses clients, même si cette heure est différente de celle du serveur A - ce qui est ce que vous voyez.

0 votes

Merci MadHatta. Le serveur B pourra-t-il toujours envoyer son heure si le serveur A est hors ligne ?

0 votes

Oui, à condition que le GPS soit en ligne ; mais si aucun des deux n'est disponible, il ne le fera pas. Si vous voulez cela, 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, et cela nécessite un meilleur matériel que les horloges de la carte mère.

0 votes

Ce n'est pas vraiment une situation idéale, mais il s'agit d'un cas d'échec. Nous devons nous assurer que les clients WinXP suivent le serveur disponible.

4voto

Brad Points 3206

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

  1. Le dispositif GPS ne fonctionne pas correctement. Il s'agit très probablement d'un problème de connectivité. Soit un pare-feu bloque les paquets, soit il n'écoute pas sur la bonne interface, soit il n'arrive pas à atteindre un signal GPS ou quelque chose de similaire. Il peut s'agir de l'indisponibilité intermittente que vous avez mentionnée. Si c'est le cas, essayez de montrer un ntpq -p de quand ça marche.
  2. Le GPS est de la strate 16. Lorsqu'il fonctionne, elle doit être de 1. Tout ce qui est supérieur à 11 va causer le même problème que vous rencontrez parce que le serveur A fera plus confiance à son horloge locale qu'à tout ce qui est à 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 de configuration devrait être une relation de peering plutôt qu'une relation circulaire maître/esclave. Utilisez l'option peer plutôt que le mot-clé server mot-clé pour cela.
  4. Le serveur A et le serveur B sont tous deux configurés pour s'utiliser 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 de 16 et ne peut pas aller plus haut.
  5. Les deux serveurs ont sélectionné leurs propres horloges comme la source de temps la plus fiable (indiquée par l'astérisque (*) à côté de l'icône de l'horloge). LOCAL source. Ils ont également réussi à se connecter l'un à l'autre. Je ne suis pas sûr de la raison pour laquelle le serveur B n'a pas choisi le serveur A comme meilleure source de temps puisqu'il a la valeur de strate la plus basse, mais c'est probablement parce qu'il a une gigue significativement plus élevée que le serveur B. LOCAL source de temps.

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

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X