Tidssynkronisering av alle nodene mot UTC (Coordinated Universal Time) kan være en dyd av nødvendighet i juridiske sammenhenger.
Tidssynkronisering av alle nodene mot UTC (Coordinated Universal Time) kan være en dyd av nødvendighet i juridiske sammenhenger. (Bilde: Istockphoto)

Klokkesynkronisering 1 av 2

Slik klokkesynk'es nettverket med offline tidsservere

Det kan være en rimelig løsning, men kvaliteten blir sjelden like bra som ved eksterne løsninger.

Opptatt av sikkerhet?

Brannmurer på fabrikker og kontorer blir tettere og tettere for hver dag som går.

NTP-pakker (se hovedtekst) bruker port 123. Dette er velkjent blant hackere, da den på enhver brannmur må stå åpen dersom man skal synkronisere klokkene mot en ekstern kilde.

Det er da en stor ulempe for NTP-poolservere og andre eksterne klokkekilder, da IT-avdelingen sjelden er glad i åpninger i brannmuren. Vi ser blant annet på intern klokkesynkronisering i en egen artikkel om eksterne tidsservere.

Kvalitetstid koster

Det første en må gjøre når synkronisering av klokkene på nettverket står på dagsorden, er å vurdere hva tiden er verdt. Hva blir de faktiske konsekvensene og kostnadene ved ikke å ha korrekte klokker? Vil det å ha relativ tid, det vil si den samme ukorrekte tiden over hele nettverket, holde for oss? Eller må vi ha absolutt tid for å gjøre susen, det vil si at samtlige noder er synkronisert mot UTC (Coordinated Universal Time)?

Juridiske årsaker

Argumentene for absolutt kontra relativ tid handler ofte om legalitet. Om en klokkeserver på et nettverk blir brukt til å tidsstemple en serie med hendelser i lukkede omgivelser, for eksempel en liten fabrikk eller på et kontor, er hovedformålet gjerne å få klokker og dataloggere til å være synkroniserte. I så fall er det kanskje ikke like viktig at tiden på nettet er identisk med UTC, så lenge alle klokkene går likt. Det er dette vi kaller relativ tid.

Absolutt tid

Dersom formålet er å kunne sette en hendelse opp mot en kjent tidsskala, for eksempel når en spesifikk bil ble tatt i en fotoboks, så er absolutt tid (UTC) et must. Den mest hyppige grunnen til at absolutt tid er å foretrekke, er når det gjelder å dokumentere et klokkeslett, juridisk sett.

Det er flere andre grunner til å ha absolutt tid også, for eksempel om man har nettverk på forskjellige lokasjoner. I så fall vil nøyaktigheten mellom de forskjellige lokasjonene kunne være lite tilfredsstillende, avhengig av hvordan man synkroniserer klokkene på de forskjellige nettene.

Ordliste

  • DCF77: Tysk langbølgeklokkesignal, et alternativ til GPS.
  • Drifting: Om en klokke har en annen hastighet enn en annen klokke.
  • GPS: GPS – Global Positioning System.
  • Leap second/skuddsekund: Inntreffer om en intern klokke hopper fra én tid til en annen.
  • NTP: Network Time Protocol.
  • NTP-poolserver: NTP-tid som hentes over internett fra en pool, det vil si flere NTP-servere. Disse er oftest synkronisert mot UTC.
  • Offset: Avvik fra UTC eller en annen klokkeserver.
  • Offline-server: Klokkeserver som ikke er synkronisert mot for eksempel GPS.
  • Online-tidsserver: Klokkeserver som er synkronisert mot offisiell kilde.
  • Stratum 1-server: Klokkeserver som er synkronisert direkte mot UTC, for eksempel ved GPS.
  • Stratum 2-server: Klokkeserver som bruker en Stratum 1-server som sin klokkekilde.
  • UTC – Coordinated Universal Time.

Tekst: Per André Horpen

Enkelte synkroniseringsmetoder er gratis, men da skorter det på nøyaktigheten.

Les også: Klokkesynkronisering med eksterne tidsservere

Enkelt med NTP

Andre løsninger har en høyere investeringskost, men det gir økt presisjon.

Vi starter med NTP (Network Time Protocol), en standard måte å synkronisere klokker på. Den spiller både på intranett og internett. Løsningen har enkelt oppsett, og NTP-klientsoftware er inkludert i de fleste operativsystemer. NTP kan kjøre på to forskjellige måter.

Les også: Slik perfeksjonerer du påliteligheten i industrielle nettverk

Beregner offset

Den mest brukte og mest nøyaktige måten går ut på at NTP-klienten regelmessig forespør serveren om tid, for å holde seg synkronisert. Klienten spør en eller flere servere om korrekt tid (t1), se figur. Serveren får forespørselen (t2) og sender klokkeslettet tilbake til klienten (t3), som klienten så mottar (t4).

Den tiden det tar fra klienten spør om korrekt tid, til den mottar svar fra serveren, er tiden det tar for dataene å reise frem og tilbake mellom klient og server. Klienten beregner så sin offset ifra serveren, ved å bruke følgende algoritme:

O = ((t2-t1)+(t3-t4))/2

Les også: Slik øker du påliteligheten i industrielle nettverk med funksjonaliteten i switchene

Kompenserer for reisetid

Kort forklart tar klienten den totale reisetiden til og fra serveren og deler den på to, hvilket gir datapakkens reisetid, én vei. Klienten tar reisetiden, legger til det klokkeslettet som serveren sendte, og bruker dette som korrekt tid. For å gi et eksempel: Dersom reisetiden var to sekunder frem og tilbake, så beregner klienten at reisetid én vei var på ett sekund.

Om avviket mellom klientens interne klokke og serverens klokke er liten, vil klienten øke eller senke sin interne klokkehastighet for å justere seg mot korrekt tid.

Pass på loggehull

Mangelfull tidssynkronisering på nettverket kan føre til uheldige omstendigheter.
Mangelfull tidssynkronisering på nettverket kan føre til uheldige omstendigheter. Istockphoto
 

Men dersom avviket er stort vil skuddsekund (leap second) inntreffe. Klienten vil, i en stor jafs, forskyve sin interne klokke til servertiden for å oppnå synkronitet. Dette vil forårsake enten hull i logger, eller doble oppføringer på samme klokkeslett, og er selvsagt ikke å anbefale.

Noen NTP-klienter kan konfigureres med flere, redundante servere. Vi skraper litt i overflaten på det omfattende temaet.

NTP-redundans

Klienten lager et vektet gjennomsnitt av alle de forskjellige klokkeslettene den mottar fra serverne, og bruker dette som sin interne klokke. Om alle serverne er innenfor det den anser som rimelig samlet, blir alle tatt med i det vektede gjennomsnittet.

Hvis derimot en eller flere avviker fra den samlede serverflokken, blir den eller de utelukket fra snittberegningen. Dette er en form for kvalitetssikring.

Uønsket drift

Desto mindre nøyaktige serverne er, desto mer vil de drifte fra hverandre. I verste fall  kan du da (sett fra klientens ståsted) ende opp med kun én server som blir ansett som pålitelig. Idet klienten fjerner den eller de upålitelige serverne fra snittberegningen, kan man få skuddsekunder.

Det er derfor viktig at alle NTP-serverne er synkronisert mot en felles kilde for å unngå at de ”vingler rundt”. Selv om en server bare drifter noen få sekunder, vil det ta lenger tid enn et par sekunder å lese loggfiler med hull og dobbeltoppføringer.

Les også: Slik kontrollerer du industrielle nettverk med virtuelle løsninger og multicast-teknologi

Interne, offline NTP

Interne, offline NTP-servere er en av de mest brukte løsningene som brukes for å synkronisere lokalnettet (intranettet). Man bruker for eksempel en pc eller en filserver (en hvilken som helst node som kan være NTP-server), og så konfigurerer man alle de andre nodene til å bruke disse enhetene som NTP-servere.

Da oppnår pc-er, PLS-er, HMI-er, og alt annet som måtte befinne seg på nettverket, korrekt tid på en enkel og rimelig måte. Skjønt, i dette eksempelet er uttrykket «korrekt tid» en stor overdrivelse.

Unøyaktige oscillatorer

Servere, pc-er og alt annet nettverksutstyr er laget for å prosessere og presentere data. Oscillatorene som sitter i utstyret er veldig kjappe, men langt fra nøyaktige. Disse oscillatorene blir lett påvirket av både temperatursvingninger og vibrasjoner, og man ser fort at tiden drifter en god slump sekunder – hver eneste dag.

Sett fra NTP-klientens ståsted vil ikke denne driftingen spille noen rolle, for klientene vil drifte i takt med serveren, og alle lever lykkelig uvitende. Men den dagen tiden på serveren blir korrigert, vil man kunne se effekten av det, i form av skuddsekunder på samtlige klienter.

Uansett om behovet er absolutt eller relativ tid, er dette ingen god løsning. I hvert fall ikke om man har et ørlite ønske om nøyaktighet, eller et håp om å kunne bruke klokken når det kommer til feilsøking. Dersom en bruker redundante NTP-servere er denne løsningen ikke å anbefale.

Les også: Slik synkroniserer du tiden i industrielle nettverk

NTP-poolservere

NTP-gruppeservere (pool servere) er nok en gratis måte å synkronisere klokker på. En stor fordel er at de er synkronisert mot UTC (Coordinated Universal Time), ofte via GPS. Mest sannsynlig er alle Stratum 1-servere.

Stratum 1 forteller at serveren er synkronisert mot for eksempel GPS, DCF77, eller en annen offisiell klokkekilde, og at de er dertil nøyaktige.

Last kontra nøyaktighet

Noen ganger blir Stratum 1-serverne brukt til å synkronisere andre klokkeservere i samme gruppe, og disse blir da referert til som Stratum 2-servere. Har man et knippe Stratum 1-servere, vil lasten på disse øke i takt ettersom flere bruker gruppen til å synkronisere klokkene sine.

Lastdeling kan for eksempel gjøres ved å sette opp flere Stratum 2-servere, som synkroniseres mot Stratum 1-serverne, for så å bruke Stratum 2-serverne for å dele klokketid med klientene. Det er bra med tanke på lastdelingen, men for hvert ledd NTP-pakkene skal gå via, degraderes nøyaktigheten.

Varierende reisetid

Som vi alle vet, er dette med redundans et meget relevant tema i industrien. Sånn sett er en NTP-pool noe å vurdere, da det er mange servere som står for å drifte en pool, kontra det å ha et par interne pc-er eller servere som NTP-servere. Men, på den annen side, så får man ikke redundans ved å bruke en NTP-server dersom man kun har en link ut mot internett.

En annen viktig ting å tenke på, som er en nøkkelfaktor for nøyaktighet og NTP-poolservere: Datatrafikk som sendes over internett går gjennom en stor mengde routere. En NTP-klients forespørsel tar en rute når den blir sendt til serveren, men svaret fra serveren kan ta en helt annen rute, som kan være lengre eller kortere. Dette gjør at klientens algoritme for å beregne reisetid for pakken, blir unøyaktig.

Les også: Klokkesynkronisering med eksterne tidsservere