Órák szinkronizálása
Írta: Reegn Zoltán, 2009. december
Ez a szócikk betekintést nyújt az időszinkronizációs módszerek közötti különbségekbe. Első lépésben áttekintjük a népszerűbb időszinkronizációs protokollokat, majd egyenként megnézünk pár időszinkronizációs csomagot, elemezzük előnyeiket/hátrányaikat.
Tartalomjegyzék |
1 Fogalmak
slewing - az időt nem korrigáljuk gyorsabban egy adott sebességnél (max. 0.5ms/s), ha egy bizonyos mértéknél(pl. 128ms-nál) kisebb az eltérés az időszinkronizációs szervertől lekért, és a saját óránk ideje között(lassítjuk/gyorsítjuk az órát)
stepping - ugrás a jó érték becslésére (az órát ugratjuk előre/vissza). Ezt a módszert célszerű csak rendszerindításkor használni, mivel kritikus folyamatokat negatívan befolyásolhat, ha visszaugrunk az időben.
2 Időszinkronizációs protokollok
2.1 DAYTIME Protocol
Az időt egy ASCII stringként adja vissza a protokollt támogató szerver. A 13-as TCP vagy UDP portot használja kommunikációra.
Hátránya, hogy kis körben használják, pontatlan, nem definiált az ASCII string pontos formátuma, ezért problémás a feldolgozása.
2.2 TIME Protocol
A 37-es TCP vagy UDP portot használja kommunikációra. A szerver az időt egy 32 bites bináris alakban küldi, ami az 1900. jan. 1. 00:00 UTC óta eltelt másodpercek számát írja le. Az ilyen formátumú időreprezentáció ~136 évet fed le másodperces felbontással.
2007-ben megkezdődött a protokoll használatának fokozatos leváltása az NTP-re ott, ahol még alkalmazzák.
Hátrány: támgatása megszűnőben van, az időbélyeg később gondokat okozhat(2036-os probléma), SNTP gyakorlatilag ugyanez, csak pontosabb.
2.3 NTP - Network Time Protocol
RFC 778 RFC 891 RFC 956 RFC 1305
A legelterjedtebb Internetes időszinkronizációs protokoll. Az időt több szervertől is megkérdezi, majd átlagolja a kapott időbélyegeket. Az átlagtól legjobban eltérő válaszokat eldobja, majd a többiből ismét átlagot számol. Ezt a második átlagot használja a pontos idő becslésére. A kommunikációt UDP/IP-n keresztül végzi, a 123-as UDP porton. Az NTP időbélyeg egy 64 bites szám, ami egy 32 bites másodperc, és 32 bites töredék másodperc részből áll. Az időbélyeg az 1900 jan. 1 00:00 UTC óta eltelt időt tárolja, felbontása ~200 ps (2^-32). Ebből következik, hogy az NTP által használt időbélyeg 2036-ban fordul át, a 2038-as Unix Millennium Bug előtt.
Előnye, hogy nagy infrastruktúra hálózat épül rá, nagy a támogatottsága, széles körben elterjedt, nem tudományos célokra elég pontosságot biztosít
Hátránya, hogy olyan időbélyeggel dolgozik, ami később gondokat okozhat (2036-os probléma)
Kapcsolódó fogalom:
stratum - ntp-nél használt fogalom. Egy hierarchikus rendszert ír le, melyben több rétegen (strata) helyezkednek el az NTP szerverek, mindegyiknek megvan a saját rétegszáma, melyből következtethetünk az általuk szolgáltatott érték pontosságára is. 0-ás rétegben vannak az atomórák és nagy pontosságú órák, az 1-es réteg az ezekhez közvetlenül kapcsolódó számítógépek. A 0-ás réteg gépei nem csatlakoznak közvetlenül az internetre.
Az NTPv4 fontosabb újdonságai az NTPv3-hoz képest:
- IPv6 címeket is kezel
- autokey nyilvános kulcsú titkosítást támogat
- Burst mód (iburst és burst)
- pontosabb óraszabályozás
- nanokernel támogatás - nanoszekundumos pontosságot biztosít
2.4 SNTP - Simple Network Time Protocol
RFC 1361 RFC 1769 RFC 2030 RFC 4330
Hasonló az NTP-hez, azonban csak egyetlen NTP szervert kérdez meg az aktuális időről (hasonlóan a daytime vagy time protokollhoz), majd ezt állítja be magának.
Előnye: egyszerűbb, mint az NTP, beágyazott rendszerekbe ezért ideális (kisebb komplexitás - kisebb számítási igény) Hátránya: vakon megbízik egy NTP szerver által szolgáltatott értékben, nem viszonyít más szerverekhez.
3 Időszinkronizációra használt programok
3.1 ntpdate
Az időt több szervertől is megkérdezi, mindekitől többször. Egy adott algoritmussal kiszűri a túl nagy eltérésű szervereket, majd a maradékból egy másik algoritmussal kiválasztja a legpontosabbat. A program pontossága függ a szerverek számától, a minták számától, és a mintavételek között eltelt időtől. Kézileg, vagy rendszerinduláshoz ütemezve ajánlott futtatni. Mivel nem lehet daemonizálni, ezért az nem szabályozza az órát a beállítás után.
Amennyiben a host időbeni eltérése a szervertől fél másodpercen belülre esik, akkor az adjtime() függvényhívással a helyes időre "sietteti" vagy "késlelteti" a host óráját. Amennyiben az eltérés fél másodpercnél nagyobb lenne, akkor a settimeofday() függvényhívással a helyes időpontra ugraszja a host óráját.
Amennyiben ntpd (ntp daemon) is fut azon a gépen, amelyiken az ntpdate-et futtatjuk, akkor az ntpdate nem állítja át az órát.
3.2 openntpd
A fejlesztők szerint az NTPv3 szabvány olyan nagy pontosságot ír le, ami egy linuxos gépen elérhetetlen. Mellőzve a túlzott pontosságot egy egyszerűbb kliensprogramot készítettek. A program ~3kloc (3 kilo line of code - 3000 sor kód), tehát nagyon kompakt. +-50ms-os pontosságot garantál, ami egy linuxos rendszer által biztosított legnagyobb pontosság.
A programban privilégium szeparációt valósítottak meg. Ez azt jelenti, hogy a program több részre van felosztva, és minden rész csak azokkal a jogokkal rendelkezik, amik a feladatának végrehajtásához szükségesek.
Az openntpd-ben a feladatokat két processz látja el:
- szülő - rootként fut. Ő végzi a kernelhívásokat, amik az időt állítják.
- ntp engine - _ntp userként ként fut. chroot-ol /var/empty-be. Ezzel lekorlátozódik a fájlrendszerelérése.
A processzek között a kommunikáció egy unix domain socket-páron keresztül történik.
A szülő és az ntp engine között használt üzenetek:
- IMSG_ADJTIME - ntp engine megkéri a szülőt, hogy hívja meg az adjtime() függvényt
- IMSG_SETTIME - ntp engine megkéri a szülőt, hogy hívja meg a settime() függvényt
- IMSG_HOST_DNS - ntpengine megkéri a szülőt, hogy oldja fel a megadott hostnevet (/etc/resolv.conf)
A szülő nem bízik a kliensében, ezért nagyon szigorú az üzenetek formátumát illetően. Ha az üzenet formátuma nem megfelelő, bontja a kapcsolatot a klienssel.
3.3 rdate
Egy szegényes időszinkronizációs program. Lekéri a szervertől az aktuális időt, majd a kapott időt állítja be a host óráján.
3.4 ntpd
Az ntpd egy időszinkronizációs daemon. A többi vizsgált időszinkronizációs módszerrel ellentétben az ntpd már támogatja az NTPv4-et, de kompatibilis maradt az NTPv3-mal is.
3.5 taiclock
A taiclock szerverek az időt TAI64NA formátumban küldik a hostoknak. A TAI64 időbélyegek előnyéről itt lehet többet olvasni. A protokoll UDP/IP fölött is működik.
3.6 chrony
Két programból álló időszinkronizációs csomag. A két program neve chronyd és chronyc. A chronyd egy daemon, amely ntp-szerverekhez szinkronizálja az időt. A következő jellemzőkkel bír:
- az időt slew módszerrel korrigálja, ha ntp szerverhez tud kapcsolódni
- nyilvántartja, hogy milyen mértékű a gép órájának pontatlansága, így két szinkronizálás között is viszonylag pontosan tartja az órát
- újraindítás vagy ki/bekapcsolások között is pontosan tartja az órát, rendszerinduláskor a nyilvántartott pontatlanságból számítja a beállítandó időt
Ezek azt eredményezik, hogy chrony-t használva, egy internetre ritkán csatlakozó gépen tovább marad pontos az idő, mint ha ntpd-t használnánk.
A chronyc egy interfészt szolgáltat a chronyd beállításaihoz. A kettejük közötti kommunikáció kliens-szerver jellegű.
4 Saját NTP-szerver konfigurálása
Alapvető példa egy /etc/ntp.conf fájlra:
# --- GENERAL CONFIGURATION --- server 0.europe.pool.ntp.org server 1.europe.pool.ntp.org server 2.europe.pool.ntp.org server 3.europe.pool.ntp.org server 127.127.1.0 fudge 127.127.1.0 stratum 10 # Drift file. driftfile /etc/ntp/drift
A legegyszerűbb konfigurációban egy NTP-szerver van. A server 127.127.1.0 sor azért kell, mert így tudjuk beállítani az extra opciókat a fudge paranccsal (pl. stratum szintet)
A drift fájl eltérés-fájl. Idővel az ntpd megtanulja, ohgy mennyi a rendszer tévedése, és ez alapján automatikusan kiigazítja a hibát.
Fontosabb konfigurációs paraméterek:
paraméter | hatás |
---|---|
server | A szinkronizációs szerver beállítása |
fudge | További paraméterek beállításának kapcsolója |
stratum 10 | Ezzel kézileg állíthatjuk be a szerverünk stratum szintjét |
driftfile | A drift fájl helyét határozhatjuk meg vele |
Ha egy szerver asszociációnak az "iburst" (initial burst) opciót adjuk meg, az azt fogja eredményezni, hogy ha a szerverrel megszakad a kapcsolat, akkor mikor újra kapcsolatba tudunk lépni vele, 8db, két-két másodpercenként küldött kérést küld az ntpd a szervernek. Így PPP vagy ISDN internetkapcsolat kiépülésekor percek helyett másodpercek alatt szinkronizál a gépünk. A "dynamic" opciót használva olyan szervert is be tudunk állítani referenciának, ami a konfiguráláskor nem elérhető. Ez az opció feltételezi, hogy a szerver valamikor elérhető lesz. példa:
server 0.europe.pool.ntp.org iburst dynamic
4.1 Restrict
A restrict opcióval korlátozhatjuk, hogy a hálózaton levő rendszerek mit csinálhatnak az NTP-szerverrel:
#A localhostnak teljes hozzáférést biztosítunk restrict 127.0.0.1 #A beállított időszinkronizációs szervereknek be kell állítani a jogosultságaikat, #hogy tudjunk róluk szinkronizálni restrict 0.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 1.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 2.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 2.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery #A belső privát hálózatunkon levő hostoknak jogokat adunk queryk küldésére restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
Az fontosabb restrict jogosultság korlátozások
korlátozás | hatás |
---|---|
ignore | az adott hálózatból érkező minden ntp csomagot eldobunk |
kod | Ha valaki túl gyakran küld lekérdezéseket, küld egy kérést a lassításra |
nomodify | Az olyan kérések tiltása, amik módosítanák az NTP-szervert |
notrap | Deny control message trap service |
noquery | NTP lekérdezések tiltása az adott hálózatból |
noserve | ntpq / ntpdc kéréseken kívül minden ntp kérést tilt |
notrust | Csak kriptgráfiailag titkosított kapcsolatok fogadása |
nopeer | Deny all packets that attempt to establish a peer association |
4.2 A szerver indítása
Első alkalommal indításkor érdemes egyet ntpdate-tel szinkronizálni, hogy legyen egy alapidő, amihez hozzáigazodik majd az ntpd.
[bash]# ntpdate -b pool.ntp.org
az ntpd.conf beállítása után újraindítjuk az ntpd-t.
[bash]# /etc/init.d/ntpd restart
A következő paranccsal megbizonyosodhatunk arról, hogy az ntp szerverünk fut:
[bash]# ntpq -p 192.168.1.1
A következőhöz hasonló kimenetet kapunk, ha elérhető az ntp szerver az adott IP-n:
remote refid st t when poll reach delay offset jitter ============================================================================== *edge.tillo.ch 192.87.106.2 2 u 14 64 1 66.171 -4.503 2.580 +dns1.rmplc.co.u 193.62.22.98 2 u 13 64 1 74.657 -4.340 1.852 -nx2.xplo-re.net 94.23.99.153 3 u 12 64 1 80.919 -13.224 1.590 +ns1.servbit.ro 80.96.120.252 2 u 11 64 1 87.840 -16.949 1.054 LOCAL(0) .LOCL. 10 l 26 64 1 0.000 0.000 0.001
A jelzések a következőket jelentik a címek előtt:
- csillag: ehez szinkronizálunk jelenleg
- +:szinkronizálásra jelölt szerver
- -:nem elég jó minőségű szerver
Amennyiben nem elérhető a szerverünk, a következőhöz hasonló hibát kapunk:
192.168.1.1: timed out, nothing received ***Request timed out
Egy másik gépről a következő paranccsal ellenőrizhetjük azt, hogy fut-e az ntp-szerver:
[bash]# ntpdate 192.168.1.1
4.3 dhcpd beállítása
Amennyiben szeretnénk a magánhálózatunk gépeit dhcp-n keresztül informálni az új időszinkronizációs szerverünk elérhetőségéről, akkor azon a gépen, ahol a dhcpdaemont futtatjuk, módosítsuk az /etc/dhcpd.conf fájlt a következőképpen:
bővítsük a subnet-re érvényes bejegyzést, ahol alkalmazni szeretnénk az új NTP-szerverünket.
subnet 192.168.1.0 netmask 255.255.255.0 { //így néz ki egy subnet bejegyzés ... option ntp-servers 192.168.1.1; //az NTP-szerverünk címe a hálózaton ... }
ezután indítsuk újra az dhcpdaemont:
[bash]# /etc/init.d/dhcpd restart