- \n
- Orsaker<\/strong>Kvartsavvikelser, virtualisering, backup-frysning, felaktig hostsynkronisering<\/li>\n
- Konsekvenser<\/strong>Kerberos-fel, f\u00f6rsenade jobb, mots\u00e4gelsefulla loggar, falsklarm<\/li>\n
- Diagnos<\/strong>Kontrollera offsets, ntpq -p, w32tm, \u00f6vervakning av larmgr\u00e4nser<\/li>\n
- L\u00f6sning<\/strong>NTP\/Chrony, PDC-emulator, avaktivera host sync, anpassa polling<\/li>\n
- \u00d6vning<\/strong>Stratum-topologi, release UDP 123, regelbundna driftkontroller<\/li>\n<\/ul>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/serverzeitdrift-it-check-5912.png\")
\n<\/figure>\n\n\nVad inneb\u00e4r egentligen servertidsdrift?<\/h2>\n\n
Server klockor<\/strong> k\u00f6rs aldrig perfekt, de driver p\u00e5 grund av temperaturfluktuationer, kristallspridning eller virtuella timers. I distribuerade system blir sm\u00e5 avvikelser snabbt stora och skapar synliga fel, t.ex. felaktigt sorterade h\u00e4ndelser eller meddelanden som behandlas f\u00f6r sent. Jag ser ofta vid revisioner att \u00e4ven sekunder kan rubba ordningen i loggpipelines och snedvrida analyser. Om belastningen \u00f6kar buffrar systemen meddelanden med lokala tidsst\u00e4mplar som senare \u00e4r minuter felaktiga och skapar f\u00f6rmodade f\u00f6rdr\u00f6jningar. Drift av servertid<\/strong> f\u00f6rblir knepigt eftersom allt fungerar korrekt lokalt tills en tj\u00e4nst j\u00e4mf\u00f6rs tv\u00e4rsnittligt eller en replikering strejkar.<\/p>\n\n
Varf\u00f6r n\u00e5gra minuter kan f\u00f6r\u00e4ndra allt<\/h2>\n\n
Kerberos<\/strong> tolererar bara ett litet tidshopp; n\u00e5gra minuters avvikelse \u00e4r tillr\u00e4ckligt f\u00f6r att \u00e4renden ska avvisas och inloggningar misslyckas. Jag har sett milj\u00f6er d\u00e4r en skillnad p\u00e5 bara 3 minuter saktade ner replikeringen och l\u00f6senordsbyten fastnade. M\u00e4tpunkter f\u00f6r latens blandas ihop: Osynkroniserade m\u00e4tnoder rapporterar pl\u00f6tsligt negativa v\u00e4rden och genererar falsklarm. I databaser f\u00f6rlorar transaktioner sin kronologiska ordning, vilket resulterar i h\u00e5rda fel i CDC-str\u00f6mmar eller event sourcing. Alla som beh\u00f6ver revisioner eller kriminaltekniska analyser misslyckas p\u00e5 grund av inkonsekventa loggar<\/strong>, om tidsst\u00e4mplar hoppar eller dubbleras.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/servertimedriftmeeting2946.png\")
\n<\/figure>\n\n\nVirtualisering: Proxmox, Hyper-V och VMware<\/h2>\n\n
hypervisor<\/strong> \u00e4ndra tidsbeteende eftersom virtuella datorer upplever virtuella timers, pauser och \u00f6gonblicksbilder. Under s\u00e4kerhetskopieringar fryser g\u00e4sten, v\u00e4rdtiden forts\u00e4tter att l\u00f6pa och g\u00e4sten faller ibland tillbaka med timmar efter \u00e5terupptagandet. Jag ser ofta dessa hopp i Windows-virtuella datorer n\u00e4r v\u00e4rdsynkronisering och g\u00e4st-NTP arbetar mot varandra. En v\u00e4rd som g\u00e5r fel inducerar ocks\u00e5 felaktiga tider till alla g\u00e4ster via timesync-integrationstj\u00e4nster, vilket drabbar Active Directory s\u00e4rskilt h\u00e5rt. Alla som arbetar i Proxmox, VMware eller Hyper-V b\u00f6r aktivt kontrollera Timesync i g\u00e4sten och specifikt st\u00e4nga av dubbelsynkronisering f\u00f6r att T\u00e4vlingsf\u00f6rh\u00e5llanden<\/strong> som ska undvikas.<\/p>\n\n
M\u00e4tning och diagnos i vardagslivet<\/h2>\n\n
Diagnos<\/strong> b\u00f6rjar med f\u00f6rskjutningen: Jag kontrollerar ntpq -p eller chronyc-k\u00e4llor och l\u00e4ser f\u00f6rskjutningarna i millisekunder till sekunder. P\u00e5 Windows ger w32tm \/query \/status anv\u00e4ndbara data; p\u00e5 Linux hj\u00e4lper timedatectl till att avg\u00f6ra om NTP \u00e4r aktivt. Loggar avsl\u00f6jar ofta \u201etiden gick bak\u00e5t\/fram\u00e5t\u201c-meddelanden som indikerar hopp. F\u00f6r en kontinuerlig \u00f6versikt har jag satt upp en enkel driftmonitor som rapporterar avvikelser fr\u00e5n referensservern och ger ett larm fr\u00e5n 100-200 ms. Om du vill g\u00e5 djupare hittar du praktiska steg i den h\u00e4r kompakta guiden: NTP och Chrony-rutiner<\/a>, som jag brukar anv\u00e4nda som en checklista.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/server-time-drift-loesung-2841.png\")
\n<\/figure>\n\n\nKonfiguration: St\u00e4ll in Windows Time Service och Linux p\u00e5 r\u00e4tt s\u00e4tt<\/h2>\n\n
F\u00f6nster<\/strong> Servrar fr\u00e5n 2016 och fram\u00e5t korrigerar drift mycket mer exakt om k\u00e4llan \u00e4r korrekt och inga konkurrerande synkroniseringstj\u00e4nster k\u00f6rs. Jag konfigurerar PDC-emulatorn som den auktoritativa k\u00e4llan, st\u00e4ller in w32tm \/config \/manualpeerlist: \u201cpool.ntp.org,0x8\u2033 och fixar pollningsintervall som matchar n\u00e4tverket och kraven. P\u00e5 Hyper-V avaktiverar jag tidssynkronisering i integrationstj\u00e4nsten f\u00f6r dom\u00e4nkontrollanter s\u00e5 att endast NTP best\u00e4mmer. Jag f\u00f6redrar att k\u00f6ra Linux-v\u00e4rdar med Chrony eftersom korrigeringarna f\u00e5r effekt snabbt och f\u00f6rskjutningarna ligger kvar p\u00e5 millisekundniv\u00e5. Det h\u00e4r \u00e4r viktigt: Dubbel synkronisering<\/strong> s\u00e5 antingen v\u00e4rdsynkronisering eller NTP i g\u00e4sten - inte b\u00e5da p\u00e5 samma g\u00e5ng.<\/p>\n\n
Active Directory: F\u00f6rst\u00e5 roller och undvik misstag<\/h2>\n\n
PDC-emulator<\/strong> best\u00e4mmer tiden i dom\u00e4nen och b\u00f6r sj\u00e4lv ha tillf\u00f6rlitliga uppstr\u00f6msk\u00e4llor, helst flera. Dom\u00e4nkontrollanter accepterar bara en liten avvikelse; om den \u00f6verskrids riskerar man att biljetten avvisas och replikeringarna misslyckas. Jag h\u00e5ller PDC-emulatorn fysiskt n\u00e4ra Stratum 1\/2-k\u00e4llor och separerar den fr\u00e5n hypervisor-tidssynkroniseringen. Jag schemal\u00e4gger s\u00e4kerhetskopior och \u00f6gonblicksbilder till DC s\u00e5 att de inte kastar bort klockan och testar \u00e5terupptagning med fokus p\u00e5 tid. Med rena roller och g\u00f6randen och l\u00e5tanden stabiliserar du Autentisering<\/strong> och replikeringsf\u00f6nstret.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/server-time-drift-buero-2984.png\")
\n<\/figure>\n\n\nArkitektur: NTP-topologier, strata och n\u00e4tverk<\/h2>\n\n
NTP<\/strong> fungerar hierarkiskt: Stratum-1 tar tid fr\u00e5n GPS\/DCF\/PTP, Stratum-2 refererar till Stratum-1 osv. Jag planerar minst tre oberoende k\u00e4llor s\u00e5 att enskilda fel eller falska peers inte dominerar. UDP-port 123 m\u00e5ste vara tillf\u00f6rlitligt tillg\u00e4nglig; paketfilter med slumpm\u00e4ssiga droppar snedvrider offsets. Genom att finjustera pollningsintervallen kan man g\u00f6ra snabba korrigeringar utan att \u00f6versv\u00e4mma n\u00e4tverket. Moderna n\u00e4tverkskort med tidsst\u00e4mpling i maskinvaran minimerar jitter och minskar Offset<\/strong> m\u00e4rkbar.<\/p>\n\n
PTP och h\u00f6gprecisionstid i datacentret<\/h2>\n\n
N\u00e4r mikrosekunderna r\u00e4knas r\u00e4cker det ofta inte med NTP. PTP (Precision Time Protocol)<\/strong> synkroniserar v\u00e4rdar via boundary och transparenta klockor i switchar ner till mikrosekundsomr\u00e5det. Jag anv\u00e4nder PTP d\u00e4r handelsfl\u00f6den, m\u00e4tsystem eller industriell automation kr\u00e4ver exakt timing. Rent praktiskt inneb\u00e4r det att man planerar en PTP-kompatibel n\u00e4tverksinfrastruktur, st\u00e4ller in VLAN och QoS s\u00e5 att asymmetriska v\u00e4gar minimeras och kopplar ihop NIC:ens PHC (ptp4l\/phc2sys) med systemklockan p\u00e5 hostarna. Chrony kompletterar NTP v\u00e4l, PTP tar \u00f6ver finkalibreringen. Viktigt \u00e4r en Rensa master-val<\/strong> (Grandmaster med GPS\/PPS) och \u00f6vervaka offsetf\u00f6rdelningen per segment, annars jagar du fantomdrift, som faktiskt \u00e4r n\u00e4tverksasymmetri.<\/p>\n\n
Containrar och Kubernetes: att bem\u00e4stra tiden i klustret<\/h2>\n\n
Containrar anv\u00e4nder v\u00e4rdens klocka - du \u201einstallerar\u201c inte tid per pod. Jag st\u00e4ller in Tidssuver\u00e4nitet p\u00e5 noderna<\/strong> s\u00e4kert (chronyd\/ntpd p\u00e5 arbetaren) i st\u00e4llet f\u00f6r att starta NTP i containrar. I Kubernetes kontrollerar jag att etcd-noder, kontrollplan och arbetare h\u00e5ller samma offset, annars blockeras val av ledare (raft\/lease durations) och certifikatrotationer. A privilegierad DaemonSet<\/strong> f\u00f6r NTP \u00e4r s\u00e4llan n\u00f6dv\u00e4ndigt; en ren nodavbildning med Chrony \u00e4r mer stabil. F\u00f6r CronJobs i klustret anv\u00e4nder jag UTC och beh\u00e5ller startDeadlineSekunder<\/em> konservativ s\u00e5 att sm\u00e5 skevheter inte leder till missade f\u00f6nster. Jag kalibrerar logg- och m\u00e4tr\u00f6rledningar (Fluent Bit, Promtail, Node-Exporter) med v\u00e4rdtid och f\u00f6rlitar mig inte p\u00e5 containrarnas tidsst\u00e4mplar.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/servertimedriftdesk8342.png\")
\n<\/figure>\n\n\nMolnmilj\u00f6er: Leverant\u00f6rstid och hybridscenarier<\/h2>\n\n
I molnet f\u00f6redrar jag att anv\u00e4nda Leverant\u00f6rstj\u00e4nster<\/strong>, eftersom latenstiderna \u00e4r korta och k\u00e4llorna \u00e4r redundanta. AWS tillhandah\u00e5ller en intern k\u00e4lla via 169.254.169.123, GCP erbjuder tid.google.com<\/em> med Leap-Smearing fungerar host timesync och klassiska NTP-peers tillf\u00f6rlitligt i Azure. Viktigt: S\u00e4kerhetsgrupper\/NSG:er m\u00e5ste till\u00e5ta UDP 123, och DC:er i molnet forts\u00e4tter att f\u00f6lja PDC-emulatorprincipen. I hybridkonfigurationer planerar jag regionala tidshubbar (t.ex. ett NTP-rel\u00e4 per VNet\/VPC) och f\u00f6rhindrar att lokala DC:er pl\u00f6tsligt \u201ev\u00e4nder\u201c till en avl\u00e4gsen molnk\u00e4lla. F\u00f6r DR-scenarier ansluter jag standbysystem till samma peers s\u00e5 att en failover inte orsakar ett tidsgap.<\/p>\n\n
Applikationsdesign: Monotona klockor, tokens och sp\u00e5rning<\/h2>\n\n
M\u00e5nga driftskador \u00e4r Konstruktionsfel<\/strong>. F\u00f6r k\u00f6rtider, timeouts och omf\u00f6rs\u00f6k anv\u00e4nder jag konsekvent monotoniska klockor (t.ex. Stopwatch, System.nanoTime, time.monotonic), inte systemtiden. Jag sparar tidsst\u00e4mplar i UTC och loggar bara tidszon f\u00f6r visning. Tokenbaserade system (JWT, OAuth2, SAML) beh\u00f6ver en liten klockf\u00f6rskjutning<\/em> (2-5 minuter) f\u00f6r exp\/nbf<\/em>, annars kommer anv\u00e4ndarna att kastas ut om det finns en liten f\u00f6rskjutning. TLS 1.3 och sessionsbiljetter utv\u00e4rderar biljett\u00e5lder, CRL:er och OCSP-validitet baserat p\u00e5 klockan - drift utl\u00f6ser on\u00f6diga omf\u00f6rhandlingar. Med Distribuerad sp\u00e5rning<\/strong> synkronisera sampler, ingest gateway och worker mot samma k\u00e4lla, annars resulterar sp\u00e4nnvidder i negativa varaktigheter. F\u00f6r m\u00e4tv\u00e4rden h\u00e5ller jag mig till tidsst\u00e4mplar p\u00e5 serversidan och undviker att agenter \u201ekorrigerar\u201c p\u00e5 klientsidan.<\/p>\n\n
Korrigeringsstrategier: Slew vs. Step, Leap Seconds och DST<\/h2>\n\n
Oavsett om en klocka sladd<\/strong> (utj\u00e4mnas l\u00e5ngsamt) eller lappt\u00e4cken<\/strong> (hoppar), beslutar om biverkningar. Chrony korrigerar mycket via slew och kan anv\u00e4ndas fr\u00e5n ett definierat tr\u00f6skelv\u00e4rde (makestep<\/em>) hoppa en g\u00e5ng. Jag planerar h\u00e5rda steg i underh\u00e5llsf\u00f6nster, stoppar tidskritiska arbetsbelastningar (t.ex. databaser, meddelandef\u00f6rmedlare) en kort stund och l\u00e5ter sedan replikering och cacheminnen komma ikapp. Under Windows begr\u00e4nsar jag stora korrigeringar via maxv\u00e4rdena och \u00e5tersynkroniserar med w32tm \/resync \/rediscover<\/em>, ist\u00e4llet f\u00f6r flera sm\u00e5 steg. Spr\u00e5ngsekunder<\/strong>Jag best\u00e4mmer mig tidigt f\u00f6r smetning eller klassisk klistring. Att smeta \u00e4r farligt - om du smetar ska du g\u00f6ra det \u00f6verallt. DST<\/strong> oro UTC<\/em> nej; jag driver servrar i UTC och reglerar visningen i applikationen. Jag kalibrerar medvetet schemal\u00e4ggare runt tids\u00e4ndringar och testar dem.<\/p>\n\n\n
\n![\"\"](\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/serverzeit-drift-9347.png\")
\n<\/figure>\n\n\nRunbook: Fr\u00e5n st\u00f6rning till stabil tid<\/h2>\n\n
N\u00e4r Drift larmar arbetar jag med en kort K\u00f6rbok<\/strong> fr\u00e5n: (1) Bekr\u00e4fta offsets p\u00e5 referensv\u00e4rden. (2) Kontrollera om duplicerade synkroniseringar \u00e4r aktiva (hypervisor sync, molnagenter, NTP\/Chrony parallell). (3) Kontrollera k\u00e4llans kvalitet (r\u00e4ckvidd, jitter, stratum). (4) Kontrollera n\u00e4tverksv\u00e4garna: UDP 123, asymmetriska v\u00e4gar, paketf\u00f6rlust. (5) F\u00f6r stora f\u00f6rskjutningar makestep<\/em> eller utl\u00f6sa w32tm resync och kort \u201et\u00f6mma\u201c kritiska tj\u00e4nster i f\u00f6rv\u00e4g. (6) Verifiera DC\/PDC-rollen och logga w32time-status. (7) \u00d6vervaka efter stabilisering: offset-trend, k\u00e4ll\u00e4ndring, kerneldisciplin. (8) Post-mortem: dokumentera grundorsaken (backup-frysning? v\u00e4rddrift? fel peers?) och f\u00f6rst\u00e4rk konfigurationen (poll-intervaller, fler peers, justera integrationstj\u00e4nster). Detta f\u00f6rfarande f\u00f6rhindrar att situationen f\u00f6rv\u00e4rras med ad hoc-steg.<\/p>\n\n
N\u00e4tverk och apparater: Osynliga driftf\u00f6rst\u00e4rkare<\/h2>\n\n
Jag ser ofta att brandv\u00e4ggar och lastbalanserare NTP-trafik<\/strong> oavsiktligt p\u00e5verka dem: ALG-funktioner, hastighetsbegr\u00e4nsningar eller asymmetrisk routing f\u00f6rvr\u00e4nger offsets. NAT-gateways med kort UDP-tillst\u00e5ndstid f\u00f6rst\u00f6r NTP-konversationer. Mitt motgift: dedikerade utg\u00e5ngspolicyer f\u00f6r UDP 123, ingen proxyskyldighet och lokala NTP-rel\u00e4er n\u00e4ra arbetsbelastningen. P\u00e5 WAN-v\u00e4gar planerar jag regionala peers i st\u00e4llet f\u00f6r centraliserade s\u00e5 att jitter fluktuerar, men Drift<\/em> f\u00f6rblir liten. QoS \u00e4r ett m\u00e5ste f\u00f6r PTP - utan prioriterade paket och transparenta switchar g\u00e5r det inte att uppn\u00e5 \u00f6nskad precision.<\/p>\n\n
Frekventa felkonfigurationer som jag hittar om och om igen<\/h2>\n\n
- \n
- En enda peer<\/strong> i konfigurationen: Om den misslyckas eller rapporterar nonsens f\u00f6ljer hela dom\u00e4nen efter.<\/li>\n
- V\u00e4rd- och g\u00e4stsynkronisering parallellt<\/strong>Hypervisor korrigerad, NTP korrigerad - hopp och sv\u00e4ngningar uppst\u00e5r.<\/li>\n
- Backup-frysning utan upptiningskrok<\/strong>Den virtuella datorn \u201evaknar\u201c med en gammal klocka; ett nedstr\u00f6ms kraftsteg saknas.<\/li>\n
- Felaktig PDC-emulator<\/strong> efter FSMO:s skift: Kunder fr\u00e5gar p\u00e5 den gamla DC, biljetter misslyckas.<\/li>\n
- Ol\u00e4mpliga pollningsintervall<\/strong>F\u00f6r l\u00e5ng f\u00f6r flyktiga n\u00e4tverk, f\u00f6r kort f\u00f6r avl\u00e4gsna peers - b\u00e5da \u00f6kar jittern.<\/li>\n
- Mix av tidszoner<\/strong> p\u00e5 servrar: UTC blandat med lokala zoner leder till ol\u00e4sliga loggar och cron-fel.<\/li>\n<\/ul>\n\n
SLA, risker och budget: Vad kostar drift?<\/h2>\n\n
Budgetplanering<\/strong> beh\u00f6ver h\u00e5rda siffror: \u00c4ven sm\u00e5 avvikelser orsakar support\u00e4renden, driftstopp eller datafel. Jag ber\u00e4knar kostnaderna konservativt med hj\u00e4lp av minuter f\u00f6r driftstopp, incidentkostnader och f\u00f6ljdskador vid revisioner. F\u00f6ljande tabell sammanfattar typiska scenarier och hj\u00e4lper till att fastst\u00e4lla prioriteringar. Den l\u00e4mpar sig v\u00e4l f\u00f6r ledningsbeslut och \u00e4ndringsbeg\u00e4ran. Siffrorna varierar beroende p\u00e5 storlek, men visar i vilken storleksordning Drift<\/strong> blir dyrt.<\/p>\n\n
\n \n
\n \nScenario<\/th>\n Typisk drift<\/th>\n Effekt<\/th>\n Risk f\u00f6r kostnader (\u20ac)<\/th>\n <\/tr>\n <\/thead>\n \n AD\/Kerberos misslyckas<\/td>\n 3-5 minuter<\/td>\n Inloggningsfel, eftersl\u00e4pning i replikeringen<\/td>\n 1.000-10.000 per h\u00e4ndelse<\/td>\n <\/tr>\n \n VM-backup med frysning<\/td>\n 10-240 minuter<\/td>\n Jobb som k\u00f6rs bak\u00e5t i tiden, avbokning av batch<\/td>\n 2.000-15.000 inkl. \u00e5terh\u00e4mtning<\/td>\n <\/tr>\n \n M\u00e4tning av nod oj\u00e4mn<\/td>\n 50-500 ms<\/td>\n Falska larm, SLO-brott<\/td>\n 500-5.000 i supporttid<\/td>\n <\/tr>\n \n Audit\/forensics misslyckas<\/td>\n sekunder-minuter<\/td>\n Loggar oanv\u00e4ndbara, risk f\u00f6r bristande efterlevnad<\/td>\n 5.000-50.000 f\u00f6r omarbetning<\/td>\n <\/tr>\n <\/tbody>\n<\/table>\n\n Anv\u00e4ndningsomr\u00e5den: Finansiell handel, e-handel, loggning<\/h2>\n\n
Finansiella system<\/strong> beh\u00f6ver konsekventa sekvenser, annars f\u00f6rlorar algoritmer sitt informationsv\u00e4rde och aff\u00e4rer utv\u00e4rderas felaktigt. Inom e-handeln p\u00e5verkar tidsfel sessionens utg\u00e5ng, rabattf\u00f6nster och orderfl\u00f6den. Jag kontrollerar noga offseten i alla gateways, betalnings- och eventsystem. I centrala loggningsstackar leder en drivande k\u00e4lla till hopp som g\u00f6r dashboards ol\u00e4sliga och f\u00f6rsenar incidentanalyser. Den som tittar p\u00e5 dessa kedjor inser snabbt hur Drift av servertid<\/strong> effekter \u00f6ver hela plattformen.<\/p>\n\n
Tid och cronjobs: f\u00f6rhindra felplanering i ett tidigt skede<\/h2>\n\n
Cron<\/strong> och uppgiftsschemal\u00e4ggare reagerar k\u00e4nsligt p\u00e5 tidshopp, till exempel under hypervisor-frysningar eller dubbelsynkroniseringar. Jobbf\u00f6nster kolliderar, repetitioner avfyras f\u00f6r tidigt eller f\u00f6r sent och hastighetsbegr\u00e4nsare g\u00e5r varma. Jag kontrollerar d\u00e4rf\u00f6r tidszoner, offset och sommartid i orkestreringen. F\u00f6r Linux-schemal\u00e4ggning undviker jag lokala klockberoenden genom att kontrollera NTP-status innan jag startar jobbet. M\u00e5nga st\u00f6testenar sammanfattas i den h\u00e4r guiden: Tidszon f\u00f6r Cron<\/a>, som jag anv\u00e4nder som en checklista inf\u00f6r go-lives.<\/p>\n\n
\u00d6vervakning och varning: f\u00f6rnuftig inst\u00e4llning av tr\u00f6skelv\u00e4rden<\/h2>\n\n
Larm<\/strong> m\u00e5ste skilja mellan jitter och verklig drift. Jag st\u00e4ller in varningar fr\u00e5n 100 ms och kritiska fr\u00e5n 500 ms, beroende p\u00e5 kraven p\u00e5 f\u00f6rdr\u00f6jning. Jag h\u00e4mtar m\u00e4tnoder fr\u00e5n olika subn\u00e4t s\u00e5 att n\u00e4tverksv\u00e4garna inte blir f\u00f6rvr\u00e4ngda p\u00e5 ena sidan. Instrumentpaneler visar mig offsets per host, trendlinjen och den senast anv\u00e4nda k\u00e4llan. Jag loggar ocks\u00e5 k\u00e4ll\u00e4ndringar s\u00e5 att jag kan Orsaker<\/strong> snabbt k\u00e4nna igen hopp.<\/p>\n\n
WordPress och schemalagda uppgifter: WP-Cron under kontroll<\/h2>\n\n
- V\u00e4rd- och g\u00e4stsynkronisering parallellt<\/strong>Hypervisor korrigerad, NTP korrigerad - hopp och sv\u00e4ngningar uppst\u00e5r.<\/li>\n
- Konsekvenser<\/strong>Kerberos-fel, f\u00f6rsenade jobb, mots\u00e4gelsefulla loggar, falsklarm<\/li>\n