1. Teorie NTP serveru
1.1 Úvod
NTP nebo-li network time protocol je protokol pro potřeby synchronizace času. Tento protokol se řadí svým věkem k jednom z nejstarších protokolů a vyvinul ho pan profesor Mills, který stále i ve svém věku působí na univerzitě Delaware a stará se o něj
Samotný NTP dokáže operovat ve dvou modelech:
-
klient-server
-
Peer-peer
Operuje na portu 123 protokolu UDP. Také může být posílán multicastem anebo broadcastem.
Při potřebe synchronizace času často řešíme dvě proměnné:
-
Přesnost
-
Rychlost
NTP protokol v tomto ohledu uspokojuje oba výše uvedené předpoklady a nyní se trochu podíváme hlouběji do střev a k podstatě elegance tohoto jednoduchého řešení.
1.2 Stratum
NTP protokol užívá model hiearchie stratu, na základě kterých probíhá ladění času. Každá vrstva má své číslené označení, které začíná od nuly. Na vrcholu strata, tedy nulté stratum jsou jak jinak atomické hodiny, od kterých se odvozuje náš svět přesného času. Další nultá strata jsou GPS a jiné rádiové hodiny. Nulté stratum produkuje velmi přesné pulzy času a jsou považovány za světovou referenci.
První stratum jsou již počítače, které mají synchronizaci nastavenou vůči nultému stratu a synchronizace proběhne v řádech mikrosekund. Často tyto stroje jsou definovány jako „primární NTP servery světa“.
Druhé stratum jsou počítače vně sítě, které jsou synchronizovány vůči prvnímu stratu, anebo se vzájemně peerují.
Třetí stratum jsou v podstatě endpointy anebo jakékoliv jiné stroje synchronizované se stratum 2, či mohou sloužit pro stratum 4 jako servery.
1.3 Algoritmus nejkratší cesty
Algoritmus pro synchronizaci NTP je složen z Bellman-Ford shortest-path spanning tree. Jinými slovy, když se nějaká mašina synchronizuje s NTP serverem, tak by cesta přes různá strata až k nultému měla být co nekratší a to, která cesta je nejkratší nám pomáhá identifikovat BF algoritmus.
A aby jakýkoliv stroj, který se chce synchronizovat měl referenční bod (místo, odkud bude definovat co je dlouhá a co je krátká cesta k nultému stratu), tak se užívá různých obecných časových sond, jako jsou například:
GOES (Geosynchronní prostředí orbitálního satelitu), nebo GPS (globální lokalizační systém), či GAL (Gallileův lokalizační systém) a dalších mnoha. Tyto sondy slouží jako bod nula, od kterého se počítá vzdálenost k nultému stratu.
1.4 Synchronizace času
Typický klient (třeba můj počítač), si vyčítá vícekrát z více NTP serverů a pak si dopočítává odchylku a zpoždění. Odchylka se počítá snadno, je to vesměs vážený průměr více hodnot a zpoždění je vypočítáno jako rozdíly hodnot. Ukažme si to konkrétněji:
Níže na grafu vidíme schéma vyobrazující klienta, který si ve dvou intervalech vezme hodnotu času. Klient v čase T0 pošle první požadavek. Než požadavek dorazí k serveru, vznikne zpoždění. Zpoždění je ekvivalentní rozdílu času T1 od T0.
Server posílá zpět odpověď. Jeho čas přechroupání je ekvivalentní rozdílů času T2 – T1. A odpověď letí dobu, která je ekvivalentní rozdílu T2-T3.
Z toho selským rozumem usoudíme, že odchylka je ekvivalentnítomuto vzorci:
A zpoždění je ekvivalentní: -\left&space;(&space;{T_{2}-T_{1}}&space;\right&space;))
Není tento protokol krásně jednoduché a elegantní?
1.5 Software implementace
Software implementace NTP protokolu jsou pak velmi různorodé. Vypícheme jen tři hlavní:
- Ve světě linuxu známe SNTP protokol, který je výrazně jednodušší než typický NTP protokol. Je prostě osekaný o nějaké fičury navíc
- Společnost Microsoft má svoji implementaci, kterou nazývá Windows Time a má své opodstatění i v praxi (synchronizace Kerberosu).
- Chrony je známá z distribucí Red Hat a je nativně také dostupná na Ubuntu. Toto řešení je zaměřené k instalaci v nestabilních prostředích (myšleno virtuální stroje, endpointy) a obecně to užívá velmi málo zdrojů
NTP server má široké použití v praxi. Nejčastěji se s ním setkáme při potřebě synchronizace času pro připojení se k doménovému řadiči, ale i když například pravidelně vyčítáme logy, nebo sbíráme data do monitoringu z různých strojů a z různých časových pásem. Také NTP vcelku elegantně řeší někdejší starou evropskou zhovadilost, které se říká přetáčení času (posuny času o jednu hodinu na jaře a na podzim. Gr).
2. Praxe NTP serverů
Teď, když jsme si pověděli něco málo o teorii, pojďme společně na praxi. Společnost Connectica s.r.o. realizovala referenční projekt pro svého zákazníka, který měl potřebu výstavby NTP serverů v redundanci. Společně si ukážeme, jak nastavit NTP server od základu.
Obecně je vhodné a žádoucí mít hned od začátku zajištěnou redundanci všeho pro docílení maximalizace efektivity. Tedy nejde jen o to, aby primární NTP server byl například na OS Debian a sekundární na OS CentOS, ale aby oba stroje nebyly například:
-
ve stejné serverovně
-
na stejném napájení/UPS
-
na stejném hardware a to navíc od stejného výrobce
-
na stejných discích od stejného výrobce
Jedině když je zajištěna maximální redundance toho, na čem to má běžět, pak má smysl stavět redundantní serverovou infrastrukturu.
2.1 Instalace NTP serveru na Debian 10
Pro naši aplikaci jsme si proto po diskuzi se zákazníkem vybrali dva OS (Debian a CentOS), zákazník zajistil redundanci železa. Na Debianu jsme rozběhli NTPd, na CentOS rozběhli Chrony.
Pro jednoduchost tohoto manuálu si ukážeme instalaci NTPd serveru na OS Debian 10.
Instalaci NTPd serveru provedeme příkazem:
apt install ntp
Po instalaci zkontroluje,e že NTP server běží
systemctl status ntp
Zkontrolujeme, že NTPd nám nastartuje i po rebootu stroje:
systemctl is-enabled ntp
Konfiguraci NTP serveru provedeme změnou konfiguračního souboru umístěného v /etc/ntp.conf
Zde si nadefinujeme nám nejbližší NTP servery, jejich seznam je dostupný zde pro různé země světa: https://www.pool.ntp.org/en/
pool <a href="http://0.us.pool.ntp.org/">0.us.pool.ntp.org</a> iburst pool <a href="http://1.us.pool.ntp.org/">1.us.pool.ntp.org</a> iburst pool <a href="http://2.us.pool.ntp.org/">2.us.pool.ntp.org</a> iburst pool <a href="http://3.us.pool.ntp.org/">3.us.pool.ntp.org</a> iburst
Volitelně si můžeme na NTP serveru nastavit i jednoduchá ACL, které nám umožní povolit nebo zakázat traffic z různých adres nebo subnetů . My toto občas užíváme (jsou-li specifické potřeby) ale jinak raději doporučujeme pravidla pro management přístupů centralizovat do jednoho místa (například na firewall) než je mít rozházená po různých strojích a vést si separátní dokumentace k nim.
Po provedení změn restarněme službu NTP server
systemctl restart ntp
A ověřme funkčnost NTP serveru příkazem
ntpq -p
Nakoukněte co vše umíme dále 😉
Výstavby DNS serverů
Jedná se o velmi častou problematiku, která je žádána jako alternativa k ADDC. Výstavba DNS serverů v redundanci na OS Debian a OS CentOS s užitím BINDu.
VPN koncentrátory na MikroTiku
Výstavba VPN koncentrátorů pro potřeby zasíťování více poboček se směrováním na jednu centrální kancelář.
Diagnostiky nízké propustnosti
Velmi často je řešena problematika diagnostiky nízkých propustností, kde hlavním pilířem je hledání bottlenecku v infrastruktuře, který může být na více místech.
Dokumentace výrobních linek
Ukázka řešení základní problematiky topologického mapování a dokumentace infrastruktury ve výrobních společnostech.
Upgrade infrastruktur
Rozsáhlé aktivity při upgrade celé infrastruktury na nejnovější verze OS a to tak, aby vše bylo sladěno a zkoordinováno bezvýpadkově pro celou společnost.
Výstavba Proxmoxových serverů
Poměrně častou problematikou společnosti je dodávka infrastuktury na klíč. Naším oblíbeným hypervizorem je Proxmox a tento druh problematiky je velmi často žádán.
