Miért életbevágó a pontos szerveridő az infrastruktúrában?
NTP időszinkron szerveren: miért okozhat hibát a pontatlan rendszeridő?
Egy szerver rendszerideje első pillantásra jelentéktelen részletnek tűnhet. Ha az óra néhány másodpercet vagy akár egy-két percet eltér a valós időtől, attól a weboldal még betöltődik, az adatbázis működik, és a legtöbb felhasználó semmit sem vesz észre.
A háttérben azonban egészen más a helyzet. A modern informatikai rendszerek jelentős része abból indul ki, hogy a szerverek, hálózati eszközök és kliensgépek órája közel azonos időt mutat. Ha ez nem teljesül, nehezen értelmezhető naplók, sikertelen hitelesítések, hibás időzített feladatok és akár biztonsági problémák is jelentkezhetnek.
Ezért a pontos szerveridő nem kényelmi funkció, hanem az infrastruktúra egyik alapvető követelménye.
Miért tud elcsúszni egy szerver órája?
A számítógépek belső órája önmagában nem tökéletes időforrás. Hosszabb működés során kisebb-nagyobb eltérés alakulhat ki, ezért a szerverek rendszeresen külső időforráshoz szinkronizálják magukat.
Erre szolgál az NTP, vagyis a Network Time Protocol.
Linux rendszereken ma többféle szolgáltatás végezhet időszinkronizációt. Gyakori például a chrony vagy a systemd-timesyncd használata. A konkrét megoldásnál fontosabb, hogy a szinkronizáció valóban működjön, és a szerver ne csak úgy gondolja magáról, hogy pontos az órája.
Virtuális gépeknél további tényező lehet a hypervisor időkezelése. Ha egy virtuális gép egyszerre próbál a virtualizációs környezetből és saját NTP-szolgáltatásából is időt szinkronizálni, rossz konfiguráció esetén furcsa eredmények jelenhetnek meg.
Ezért Proxmox, VMware vagy más virtualizációs környezet használatakor az időszinkronizációt is az infrastruktúra részeként kell megtervezni.
A hibás idő a naplóelemzést is megnehezíti
Egy incidens vizsgálatakor az egyik legfontosabb információ az események pontos sorrendje.
Tegyük fel, hogy egy webszerver 14:03:15-kor hibát naplóz, a mögötte működő adatbázis szerint azonban az esemény 14:01:48-kor történt, a tűzfal pedig 14:05-ös időbélyeggel rögzíti ugyanazt a kapcsolatot.
Ha az egyes gépek órája nincs szinkronban, már néhány perc eltérés is rendkívül megnehezítheti annak rekonstruálását, hogy valójában mi történt.
Ez különösen fontos több szerverből álló infrastruktúrában, ahol a webszerver, adatbázis, reverse proxy, levelezőszerver, monitoring és hálózati eszközök külön rendszereken futnak.
A pontos idő nélkül a naplók ugyan megvannak, de egymással nehezen összevethetők.
A kétlépcsős hitelesítés is érzékeny az időre
A Google Authenticatorhoz hasonló alkalmazásokban használt TOTP-alapú kétlépcsős azonosítás időalapú kódokat generál.
A rendszer lényege, hogy a szerver és a telefon ugyanabból a titkos kulcsból és az aktuális időből számítja ki a rövid ideig érvényes kódot.
Ha a szerver órája jelentősen eltér, előfordulhat, hogy a felhasználó teljesen helyes kódot ír be, a rendszer mégis elutasítja.
A probléma ilyenkor megtévesztő lehet. A felhasználó arra gondol, hogy rosszul állította be az Authenticator alkalmazást, esetleg hibás a titkos kulcs, miközben valójában a szerver órája csúszott el.
Egy megfelelően konfigurált időszinkronizáció ezt a hibaforrást gyakorlatilag megszünteti.
TLS és tanúsítványok esetén is számít az idő
A HTTPS működéséhez használt TLS-tanúsítványok meghatározott időintervallumban érvényesek.
A rendszer ellenőrzi, hogy az adott tanúsítvány az aktuális időpontban használható-e. Ha egy gép órája jelentősen rossz időt mutat, előfordulhat, hogy egy egyébként teljesen érvényes tanúsítványt még nem érvényesnek vagy már lejártnak érzékel.
Szerveroldalon hasonló problémák jelentkezhetnek külső HTTPS API-k elérésekor.
Ilyenkor a rendszergazda elsőként gyakran tanúsítványhibára, hibás CA-csomagra vagy TLS-konfigurációs problémára gyanakszik, pedig érdemes azonnal ellenőrizni a rendszeridőt is.
A cron feladatoknál az időzóna külön kérdés
A pontos rendszeridő és a helyesen beállított időzóna két külön dolog.
Egy szerver órája lehet technikailag tökéletesen szinkronizálva, miközben a rendszer UTC időzónát használ. Ez önmagában nem hiba. Sok szerveren kifejezetten célszerű UTC-ben tartani a rendszeridőt.
A problémák akkor kezdődnek, amikor egy alkalmazás, egy cron feladat és a rendszergazda eltérően értelmezi az időpontokat.
Ha például egy feladatnak minden nap magyar idő szerint 18 órakor kell lefutnia, tisztázni kell, hogy a cron milyen időzóna alapján dolgozik.
A nyári és téli időszámítás további eltérést okozhat, ha egy alkalmazás fix UTC-eltolással számol ahelyett, hogy valódi időzóna-információt használna.
Ezért egy „rosszkor futó cron” problémánál nemcsak magát a cront érdemes ellenőrizni, hanem a szerver és az alkalmazás időzóna-beállításait is.
Monitoringnál is szükség van pontos időre
Nagios, Zabbix és más monitoringrendszerek folyamatosan időbélyeggel ellátott adatokat gyűjtenek.
CPU-terhelés, tárhelyhasználat, hálózati forgalom, szolgáltatások kiesése vagy egy szerver újraindulása mind egy konkrét időponthoz kapcsolódik.
Ha a megfigyelt rendszer órája hibás, az események időrendje félrevezető lehet.
Még kellemetlenebb a helyzet akkor, ha több monitoringforrásból próbálunk egy incidenst rekonstruálni. Egy hálózati kapcsolat megszakadását például rögzítheti a router, a VPN-végpont, a szerver és maga a monitoringrendszer is.
A pontosan szinkronizált órák segítségével ezek az események összeilleszthetők egyetlen idővonalra.
Néhány másodperc eltérés általában még nem probléma
Nem kell abból kiindulni, hogy minden gépnek ezredmásodperc pontossággal ugyanazt az időt kell mutatnia.
A legtöbb hagyományos webes és üzleti rendszerben néhány másodperces eltérés nem okoz gyakorlati problémát.
A fontos az, hogy a szerver rendelkezzen megbízható időforrással, a szinkronizáció működjön, és az eltérés ne növekedjen folyamatosan.
Éppen ezért nem elég egyszer kézzel beállítani az órát. A rendszernek folyamatosan korrigálnia kell a természetes időeltérést.
Az NTP működését is érdemes felügyelni
Egy telepített időszinkronizációs szolgáltatás még nem jelenti azt, hogy valóban megfelelő időforrásból dolgozik.
Előfordulhat hálózati probléma, hibás konfiguráció, tűzfalszabály vagy elérhetetlen NTP-szerver.
Üzemeltetett infrastruktúrában ezért érdemes ellenőrizni, hogy a gép ténylegesen szinkronizált állapotban van-e, és mekkora az aktuális időeltérés.
Nagyobb rendszerekben akár saját belső időforrások használata is indokolt lehet, amelyekhez a szerverek és hálózati eszközök egységesen kapcsolódnak.
Így nem minden eszköz külön-külön próbál külső szolgáltatásokhoz kapcsolódni, és az infrastruktúrán belül is konzisztens idő használható.
Egy apró beállítás, amely sok hibakeresést megspórolhat
A pontos idő tipikusan olyan infrastruktúraelem, amelyről addig szinte senki nem beszél, amíg működik.
Amikor viszont elromlik, egymástól látszólag teljesen független hibák jelenhetnek meg: nem fogadja el a rendszer a kétlépcsős azonosító kódját, értelmezhetetlenné válik a naplók sorrendje, hibásnak tűnik egy tanúsítvány, vagy rossz időpontban indul el egy automatizált feladat.
Az 1B Telecom rendszerüzemeltetési és monitoringfeladatai során ezért az időszinkronizációt is az alapvető rendszerbeállítások részeként kezeljük.
Egy jól működő szerver nemcsak gyors és elérhető. A hálózat, a DNS, a mentések, a naplózás és a monitoring mellett az is fontos, hogy minden rendszer ugyanazt értse azon, hogy pontosan mikor történt egy esemény.