Unix-tip: NTP Commando’s

ITworld.com – Stuur vandaag nog uw Unix-vragen in!

Bekijk meer Unix-tips en trucs

In de column van vorige week werd NTP geïntroduceerd, het Network Time Protocol en het concept van zeer nauwkeurige tijdwaarneming. Hoewel er talloze commando’s bestaan om systeembeheerders te helpen de tijd vrij nauwkeurig bij te houden op de systemen die zij beheren, zijn de meest voor de hand liggende zeer beperkt. Als gevolg daarvan hebben de meeste netwerken last van grote afwijkingen in de systeemtijd. Tijdsverschillen zoals hieronder (genomen van een echt netwerk) zijn niet ongewoon:

host01: Thu Oct 14 10:50:23 EDT 2004

host02: Thu Oct 14 10:43:53 EDT 2004

host03: Thu Oct 14 10:41:52 EDT 2004

host04: Thu Oct 14 10:50:13 EDT 2004

host05: Thu Oct 14 10:33:59 EDT 2004

host06: Thu Oct 14 14:48:17 GMT 2004

host07: Thu Oct 14 10:52:04 EDT 2004 *

host08: Thu Oct 14 10:52:33 EDT 2004

host09: Thu Oct 14 10:49:55 EDT 2004

host10: Thu Oct 14 10:33:20 EDT 2004 *

host11: Thu Oct 14 10:51:22 EDT 2004

Alleen al binnen deze elf opeenvolgend gepeilde systemen zien we een aanzienlijke variatie in de gerapporteerde tijd. Hoewel de polls binnen een paar seconden plaatsvonden, zijn de tijdsverschillen aanzienlijk groter dan een paar seconden. Er is in feite een verschil van 18 minuten en 44 seconden tussen de vroegste en de laatste gerapporteerde tijd.

Om systemen als deze dichter bij elkaar te krijgen, kan de systeembeheerder een aantal commando’s gebruiken, met wisselend succes.

Het datumcommando

Het datumcommando, waarmee de systeembeheerder de datum en tijd kan instellen, is het meest voor de hand liggende commando om de tijd op een systeem te corrigeren, maar hangt af van de vraag of de systeembeheerder een vrij nauwkeurige tijdreferentie heeft. Ook dit commando wordt op één systeem tegelijk uitgevoerd. Als een systeembeheerder het datumcommando gebruikt om twee systemen synchroon te zetten, is het onwaarschijnlijk dat de systeemtijden dichter dan een paar seconden bij elkaar komen te liggen. Het date commando is duidelijk niet het commando bij uitstek als synchronisatie belangrijk is. En op een netwerk met enkele honderden systemen kan deze aanpak zowel vervelend als onnauwkeurig zijn.

Als een systeembeheerder een datumcommando geeft in een lus zoals hieronder, dan zouden de systeemtijden dichter bij elkaar liggen dan hierboven, maar blijven variëren met net zoveel seconden als de lus nodig heeft om te voltooien. En natuurlijk zal deze tijdvariatie steeds groter worden als voor elk ssh commando een wachtwoord moet worden ingevoerd.

for host in `cat host_list`do ssh $host "date 10141045"done

Het datumcommando is duidelijk slechts minimaal bruikbaar voor het synchroniseren van systemen. Systeemklokken die de neiging hebben tijd te winnen of te verliezen, al is het maar een paar seconden per dag, zullen de tijdskloven snel weer groter maken. Bovendien zouden systemen die zijn geconfigureerd voor andere tijdzones — zoals het ene systeem dat de tijd rapporteert als GMT in de lijst hierboven, hun klokken met uren zien afwijken als we het date commando zouden gebruiken zoals getoond.

Het rdate commando

Het rdate commando, een veel betere keuze voor het synchroniseren van klokken op een netwerk, vereist dat een systeembeheerder één systeem selecteert dat toegankelijk is voor zijn/haar netwerk, waarschijnlijk één dat redelijk nauwkeurige tijd bijhoudt om te gebruiken als tijdreferentie voor de rest.

De volgende lus zou veel betere resultaten opleveren dan de hierboven getoonde. De tijd die nodig is om deze lus te voltooien heeft immers geen nadelig effect, omdat elk rdate commando synchroniseert met de tijd op de referentieserver wanneer dat commando wordt uitgevoerd.

for host in `cat host_list`do ssh $host "rdate timekeeper"done

Daarnaast overschrijft het rdate commando niet de tijdzone op het doelsysteem. In plaats van de tijd letterlijk in te stellen op een waarde die wordt opgegeven op de opdrachtregel, vraagt rdate tijdgegevens op die onafhankelijk zijn van de tijdzone. Met andere woorden, als je “rdate ” uitvoert op een systeem dat GMT gebruikt, zal de tijd op het GMT systeem correct worden ingesteld.

Het rdate commando wordt over het algemeen uitgevoerd bij het opstarten van het systeem of via cron eenmaal per dag of eenmaal per uur om klokken op systemen op een LAN gelijk te zetten. Vergeleken met de ongedisciplineerde systeemklokken die eerder werden getoond, is dit een grote verbetering. Echter, vanuit het oogpunt van elk systeem waarvan de klok wordt gereset met rdate, kunnen er enkele zeer ongebruikelijke dingen gebeuren. Klokken kunnen vooruit of achteruit springen in de tijd telkens als het rdate commando wordt uitgevoerd. Dit gedrag kan leiden tot een aantal zeer vreemde interpretaties van tijdgevoelige gebeurtenissen.

NTP Commando’s

NTP heeft duidelijk aanzienlijke voordelen boven de date en rdate commando’s. Zo biedt NTP een manier om systeemklokken met ongebruikelijke precisie te synchroniseren en om benodigde aanpassingen soepel uit te voeren, waarbij de sprongen in de tijd die commando’s als rdate vaak veroorzaken, worden vermeden.

NTP biedt twee commando’s om de tijd aan te passen: het ntpdate commando — dat de systeemtijd instelt zoals het rdate commando dat doet (d.w.z, door te verwijzen naar een systeem op afstand om de huidige tijd te verkrijgen) en de NTP daemon — ntpd of xntpd — die een veel uitgebreider mechanisme biedt voor het bereiken van en synchroniseren met de juiste tijd.

Het ntpdate commando

Het ntpdate commando — over het algemeen gebruikt, net als het rdate commando, bij het opstarten van het systeem, op verzoek of periodiek via cron — synchroniseert de tijd op een “ad hoc” basis op een vergelijkbare manier als rdate. Het ntpdate commando heeft echter twee zeer belangrijke voordelen boven rdate.

Tpdate verwijst bijvoorbeeld naar een NTP server, niet alleen naar een betrouwbare tijdwaarnemer die toegankelijk is voor je netwerk. Omdat NTP servers over het algemeen zijn gekoppeld aan de NTP hiërarchie (en, uiteindelijk aan een zeer nauwkeurige atoomklok), zijn ze bijna gegarandeerd nauwkeuriger dan elke server die gewoon een goede klokchip heeft.

Een ander voordeel is dat ntpdate een aantal tijdmonsters kan verzamelen van een aantal tijdbronnen (dat wil zeggen, meerdere NTP servers) en dan de tijd kan selecteren die het meest nauwkeurig lijkt. Dus, niet alleen verwijst het ntpdate commando naar een tijdbron die waarschijnlijk nauwkeuriger is dan de bronnen die zijn geselecteerd voor gebruik met rdate, maar het verwijst naar een aantal van dergelijke systemen en past een verfijnd selectieproces toe.

Een ntpdate commando zou er als volgt uit kunnen zien:

# ntpdate 129.6.15.28

14 Oct 10:52:41 ntpdate: adjust time server 129.6.15.28 offset -0.003350 sec

In feite, als het ntpdate commando op uw systeem is geïnstalleerd (/usr/sbin/ntpdate op de meeste Solaris systemen), zou u dat exacte ntpdate commando nu kunnen proberen. De referentieserver in dit voorbeeld is een NTP-server bij NIST in Gaithersburg, Maryland.

Aternatief zou u een ntpdate commando als volgt kunnen proberen:

# ntpdate 129.6.15.28 216.200.93.8 208.184.49.9

14 Oct 14:57:41 ntpdate: adjust time server 216.200.93.8 offset 0.015733 sec

In dit geval worden meerdere NTP servers geraadpleegd.

De NTP Daemon

Hoewel het ntpdate commando een niveau van tijdcontrole biedt dat een orde van grootte beter is dan rdate, gaat de NTP daemon een reuzenstap verder dan ntpdate met zijn verfijnde algoritmen voor het maximaliseren van nauwkeurigheid en betrouwbaarheid. Bij goed gebruik gebruikt de NTP daemon ook een minimale hoeveelheid netwerkbronnen — we zullen dit probleem volgende week onderzoeken.

De NTP daemon biedt verfijnde algoritmen die de systeemklokken soepel synchroniseren door middel van een proces van opeenvolgende benaderingen. Hoe langer de daemon draait, hoe beter de systeemtijd overeenkomt met die van de bron. Het maakt snel grote aanpassingen en vervolgens kleinere aanpassingen in de tijd om te voorkomen dat de juiste tijd wordt overschreden.

Het kan minuten of uren duren voordat NTP een fijn nauwkeurigheidsniveau benadert, maar als dat eenmaal gebeurt, kan de betrouwbaarheid van de tijd op het systeem verbluffend nauwkeurig zijn. Dat gezegd hebbende, de nauwkeurigheid van NTP is echter, uiteindelijk, gebonden aan de nauwkeurigheid van de tijdbronnen waar het naar verwijst. Elke NTP server probeert te synchroniseren met UTC (d.w.z., Universal Coordinated Time) gebruikmakend van de beste tijdbron en het best beschikbare transmissiepad. Indien de set van servers waarnaar wordt verwezen tijden uitzenden die niet in elkaars nabijheid liggen, zal NTP een of meer van deze tijdservers als defect beschouwen en deze buiten beschouwing laten. Dus, om een nauwkeurige tijd te krijgen met NTP, moet uw keuze van tijdservers nauwkeurig zijn.

Nieuwkomers in NTP zouden moeten opmerken dat het draaien van het NTP daemon proces een systeem NIET noodzakelijkerwijs een NTP server maakt. Of een systeem dat NTP ondersteunt de rol van client of server speelt, wordt bepaald door de configuratiebestanden van de daemon op dat systeem — iets wat we in de column van volgende week zullen onderzoeken.

Dit verhaal, “Unix Tip: NTP Commands” is oorspronkelijk gepubliceerd door ITworld.