Zeitsynchronisation in einer heterogenen Umgebung

Question

Was ist in einer gemischten Umgebung, in der die meisten Computer unter Windows, einige unter Linux und manchmal unter Android laufen, die beste Lösung für eine Zeitsynchronisierung mit einer Genauigkeit von nahezu Millisekunden?

Wir entwickeln eine Lösung auf Basis von Mikrodiensten, bei der die Dienste auf mehreren Maschinen innerhalb unserer Setups verteilt sind. In vielen Situationen erfordert die Konsolidierung von Informationen zwischen ihnen (Protokolle, Überwachung usw.) eine gemeinsame Zeitbasis.

Die Verwendung von NTP unter Windows scheint mit gewissen Einschränkungen verbunden zu sein. Gibt es eine Open-Source-Lösung, die auf diesem Betriebssystem ausgeführt werden kann? Wir können nicht garantieren, dass in unseren Setups immer eine Linux-Maschine vorhanden ist.

Answer 1

[BEARBEITEN] Eine umfassende Neufassung mit Referenzen, da ich die alte Antwort einfach aus dem Gedächtnis notiert habe.

Kurze Antwort: Nein.Heutzutage ist es nicht möglich, mit einem gewöhnlichen Betriebssystem auf einer x86/x64-Plattform eine Genauigkeit im Millisekundenbereich zu erreichen.

HAFTUNGSAUSSCHLUSS Dies ist eine Laienantwort, da ich ein gewöhnlicher Systemadministrator mit der Computersicht eines gewöhnlichen Systemadministrators bin. Einige Kernelentwickler und Hardwarearchitekten verfügen wahrscheinlich über professionelle Kenntnisse in der Zeitmessung.

Lange Antwort:

Irgendwo muss man ja anfangen. Ich werde von oben nach unten vorgehen, beginnend mit den Anwendungen und mich dann zu den Oszillatoren vorarbeiten.

Das erste Problem besteht nicht darin, die Zeit auf einem Computer zu messen, sondern die Umgebung als Ganzes dazu zu bringen, sich auf die von Ihnen gewählte Zeit zu einigen. Welche Zeitmessung? Es stellt sich heraus, dass es heutzutage mehrere Möglichkeiten gibt, die Zeit auf einem Computer zu messen. Die am häufigsten verwendete ist die Systemzeit (wie in einer der Ecken des Bildschirms angezeigt). Beginnen wir damit, so zu tun, als wäre es so einfach und machen die Dinge ein paar Absätze weiter unten komplizierter.

Wir möchten, dass die Systemzeit korrekt ist und dass sie auf allen unseren Computern einheitlich ist. Wir benötigen eine Möglichkeit, sie von einer vertrauenswürdigen Quelle aus auf einer so detaillierten Ebene zu kommunizieren, dass sie unseren Anforderungen, wie auch immer sie aussehen, gerecht wird.

Legen wir für unsere Anforderung eine Toleranzgrenze von 1 ms fest. Das heißt, unsere Zeit kann innerhalb unserer Umgebung um 1 ms abweichen oder wir verfehlen ein kritisches Ziel. Werden wir konkret und schauen wir uns an, was Microsoft für uns tun kann.

Mit Ausnahme veralteter Versionen wie NT basiert die Zeitmessung bei Windows Native entweder auf vereinfachtem NTP (Computer, die einer Domäne angehören, ab XP/2003) oder vereinfachtem SNTP (Computer, die nicht einer Domäne angehören, ab Win2k) – Danke an @Ryan für die Spitzfindigkeit in diesem Detail.Microsoft hat sich zwei Ziele gesetztbei der Implementierung der Zeitmessung, die beide nicht den von uns gewünschten Genauigkeitsgrad aufweisen:

„Wir übernehmen keine Garantie und keinen Support für die Genauigkeit des W32Time-Dienstes zwischen Knoten in einem Netzwerk. Der W32Time-Dienst ist keine voll funktionsfähige NTP-Lösung, die zeitkritische Anwendungsanforderungen erfüllt. Der W32Time-Dienst ist in erster Linie für Folgendes konzipiert:

• Sorgen Sie dafür, dass das Authentifizierungsprotokoll Kerberos Version 5 funktioniert.
• Stellen Sie für die Synchronisierung der Clientcomputer eine lockere Zeit zur Verfügung.

Der W32Time-Dienst kann die Synchronisierungszeit nicht zuverlässig im Bereich von einer bis zwei Sekunden einhalten. Solche Toleranzen liegen außerhalb der Designspezifikation des W32Time-Dienstes."

OK. Angenommen, wir führen Ihren Service-Stack auf mehr als einem Computer aus und haben eine Zeittoleranz von fast 1 ms für die Ereigniskorrelation, dann ist das eine ziemliche Enttäuschung. Wenn der Service-Stack zwei Computer umfasst, können wir die native Zeitmessung von Windows eigentlich gar nicht verwenden. Aber wenn wir schon dabei sind, wollen wir ein oder zwei wichtige Punkte zur nativen Zeitmessung von Windows hervorheben und eine ausführliche Dokumentation beifügen:

Wenn Sie ein AD haben, beachten Sie, dass die Zeit in einer bestimmten Domäne von der PDC-Emulator-Rolle synchronisiert wird, je nachdem, welcher DC sie hat. Die korrekte Zeit in die Domäne zu bringen, muss daher über den Domänencontroller erfolgen, der die PDC-Emulator-Rolle ausführt. In einem Mehrdomänen-Forest wird dies auf den PDC-Emulator der Forest-Stammdomäne übertragen. Von dort wird die Zeit hauptsächlich auf die PDC-Emulatoren der Subdomänen und auf jedes Domänenmitglied verteilt (mit einigen Einschränkungen). Dieser Prozess isthier dokumentiertNoch mehr vertiefende InformationenHier

OK. Was können wir tun?

Zunächst einmal brauchen wireinsoderanderegenauere Möglichkeit, die Zeit in der gesamten Umgebung zu synchronisieren. Vorausgesetzt, wir können Linux ntpd nicht ausführen oderntpd für WindowsSie könnten einen Blick auf einen Shareware-Client namens werfenTardis, aber es gibt wahrscheinlich noch viele weitere, die man ausprobieren kann.

Wir haben Tardis auf einem Win2k3-Server als PDC-Emulator laufen lassen, dessen CMOS-Uhr eine sehr große Abweichung aufwies. Aus unerklärlichen historischen Gründen hatten wir keine andere Wahl, als das gesamte Netzwerk damit zu synchronisieren. Jetzt wurde sie zur großen Freude durch einen dedizierten Linux-ntpd ersetzt, der die Zeit von Atomuhren von außen bezieht, aber Tardis hat uns damals und dort bewundernswert gerettet.Ich weiß jedoch nicht, ob es Ihnen helfen könnte, eine höhere Präzision als die native Windows-Version zu erreichen.

Aber gehen wir von diesem Punkt an davon aus, dass wir herausgefunden haben, wie man eine perfekte Ersatz-Netzwerkzeitsynchronisierung implementiert. Durch seine inhärente Raffinesse hat es eine Kapazität für Toleranzwerte unter einer Millisekunde. Wir haben es eingerichtet, um durchzusetzen, wie unser AD erwartet, dass sich die Zeit im Netzwerk ausbreitet.

Bedeutet dies, dass wir aus Betriebssystemen und Mikrodiensten genaue Diagnosen mit einer Genauigkeit von nahezu einer Millisekunde erhalten können?

Sehen wir uns an, wie Betriebssysteme auf der x86/x64-Architektur die Prozessorzeit planen.

Sie verwenden Interrupts, dieVielfältige Tiere, reich an archäologischer Substanz. Das Betriebssystem ist jedoch nicht das einzige, das unterbrechen möchte. Auch die Hardware möchte unterbrechen und hat die Mittel dazu! (Hallo Tastatur) Und die Betriebssysteme spielen mit.

Hier wird es kompliziert und ich werde es durch Vereinfachung lösen. Fragen? Ich ducke mich, gehe in Deckung und zeige Sie auf eineabsolut hervorragende Abhandlung zu diesem Thema. (Wenn Sie Millisekunden auf einer Windows-Plattform jagen, sollten Sie es unbedingt lesen.) Eine aktualisierte Version für Win8.1/Win2012r2 istBerichten zufolge in ArbeitEs ist jedoch noch kein Veröffentlichungstermin bekannt geworden.

OK, Interrupts. Immer wenn etwas in einem Betriebssystem passieren soll, löst ein Interrupt die folgende Aktion aus. Die Aktion ist eine Reihe von Anweisungen, die vom Kernel abgerufen werden und in einemganze Mengevonverschiedene Manieren. Unterm Strich lässt sich sagen, dass der genaue Zeitpunkt der nachfolgenden Ausführung im Allgemeinen nicht bestimmt werden kann, obwohl der Interrupt zu einem Zeitpunkt erfolgt, der je nach Hardwarearchitektur und Interrupt-Behandlung des Kernels mehr oder weniger genau bestimmt werden kann. Ein bestimmter Befehlssatz kann früh oder spät nach dem Interrupt ausgeführt werden, er kann in einer vorhersehbaren Reihenfolge ausgeführt werden oder nicht, er kann Opfer fehlerhafter Hardware oder schlecht geschriebener Treiber sein, die Latenzen verursachen, die kaum zu erkennen sind. Meistens weiß man es einfach nicht. Der Zeitstempel auf Millisekundenebene, der in der nachfolgenden Protokolldatei angezeigt wird -es ist sehr präzise, ​​aber stimmt auch der Zeitpunkt des Ereignisses?

Lassen Sie uns kurz beim Zeiterfassungs-Interrupt verweilen. Ein Interrupt hat eine Prioritätsstufe. Die niedrigste Stufe ist die, auf der Benutzeranwendungen (wie ein Standarddienst) ihre Prozessorzeit erhalten. Die anderen (höheren) Stufen sind für Hardware und Kernelarbeit reserviert. Wenn ein Interrupt auf einer Stufe über der niedrigsten Stufe eintrifft, tut das System so, als ob alle ebenfalls in der Warteschlange befindlichen Interrupts mit niedrigerer Priorität nicht vorhanden wären (bis Interrupts mit höherer Priorität bearbeitet wurden). Die laufenden normalen Anwendungen und Dienste stehen auf diese Weise an letzter Stelle in der Warteschlange für die Prozessorzeit. Im Gegensatz dazu wird dem Takt-Interrupt fast die höchste Priorität eingeräumt. Die Aktualisierung der Zeit wird in einem System fast immer durchgeführt. Dies ist eine fast kriminelle Vereinfachung der Funktionsweise, dient aber dem Zweck dieser Antwort.

Die Aktualisierungszeit besteht eigentlich aus zwei Aufgaben:

• Aktualisieren der Systemzeit / AKA der Wanduhr / AKA was ich sage, wenn mich jemand fragt, wie spät es ist / AKA das Ding, bei dem NTP im Verhältnis zu nahegelegenen Systemen ein bisschen hin und her rumfummelt.

• Aktualisieren der Tick-Anzahl, wird beispielsweise zum Messen der Dauer einer Codeausführung verwendet.

Aber woher bekommt das System die Zeit, egal ob es sich um die Wandzeit oder die Tick-Zählung handelt? Das hängt stark von der Hardwarearchitektur ab. Irgendwo in der Hardware ticken ein oder mehrere Oszillatoren, und dieses Ticken wird übereinsvonmehreremöglichPfadein eine Schnittstelle für den Kontakt mit dem Kernel, während dieser mit mehr oder weniger Präzision und Genauigkeit seine Wandzeit und Tick-Anzahl aktualisiert.

Es gibt mehrere Designmodelle für die Platzierung von Oszillatoren in einem Multicore-System. Der Hauptunterschied scheint die synchrone oder asynchrone Platzierung zu sein. Diese Modelle und ihre jeweiligen Herausforderungen für eine genaue Zeitmessung werden hier beschrieben.Hierzum Beispiel.

Kurz gesagt, die synchrone Zeitmessung hat eine Referenzuhr pro Multicore, deren Signal an alle Kerne verteilt wird. Die asynchrone Zeitmessung hat einen Oszillator pro Kern. Es ist erwähnenswert, dass die neuesten Intel-Multicore-Prozessoren (Haswell) eine Art synchrones Design verwenden, das einen seriellen Bus namens „QuickPath Interconnect“ mit „Forwarded Clocking“ verwendet, siehe auch.Datenblatt. Das Forwarded Clocking wird in Begriffen beschrieben, die ein Laie (ich) schnell oberflächlich verstehen kannHier.

OK, nachdem wir nun all das Nerd-Zeug hinter uns gebracht haben (das gezeigt hat, dass die Zeitmessung eine komplexe praktische Aufgabe mit viel lebendiger Geschichte ist), wollen wir uns nun die Interrupt-Behandlung genauer ansehen.

Betriebssysteme handhaben Interrupts mit einer von zwei unterschiedlichen Strategien: tickend oder ticklos. Ihre Systeme verwenden die eine oder die andere, aber was bedeuten die Begriffe?

Tickende KerneSenden Sie Interrupts in festen Intervallen. Das Betriebssystem kann die Zeit nicht mit einer feineren Auflösung als dem Tick-Intervall messen. Selbst dann kann die tatsächliche Verarbeitung, die mit der Ausführung einer oder mehrerer Aktionen verbunden ist, durchaus eine Verzögerung aufweisen, die größer ist als das Tick-Intervall. Betrachten Sie beispielsweise verteilte Systeme (wie Mikrodienste), bei denen Verzögerungen, die bei Inter-Service-Aufrufen auftreten, relativ viel Zeit in Anspruch nehmen können. Dennoch ist jeder Befehlssatz mit einem oder mehreren Interrupts verknüpft, die vom Betriebssystem mit einer Auflösung gemessen werden, die nicht feiner ist als die Kernel-Tickzeit. Die Tick-Zeit hat einen Basiswert, kann aber zumindest in Windows bei Bedarf von einer einzelnen Anwendung verringert werden. Dies ist eine Aktion, die verbunden istnicht nur mit Nutzen, sondern auch mit Kostenund trägtziemlich viel Kleingedrucktesdamit.

Sogenanntticklose Kernel(die einen sehr nichtssagenden Namen haben) sind eine relativ neue Erfindung. Ein tickless-Kernel legt die Tick-Zeit in variablen Intervallen fest (so lange wie möglich in die Zukunft). Der Grund dafür ist, dass das Betriebssystem den Prozessorkernen dynamisch erlaubt, so lange wie möglich in verschiedene Ruhezustände zu wechseln, mit dem einfachen Ziel, Strom zu sparen. „Verschiedene Zustände“ umfassen die Verarbeitung von Anweisungen bei voller Geschwindigkeit, die Verarbeitung mit verringerter Geschwindigkeit (d. h. langsamere Prozessorgeschwindigkeit) oder gar keine Verarbeitung. Verschiedene Kerne dürfen mit unterschiedlichen Geschwindigkeiten arbeiten, und der tickless-Kernel versucht, die Prozessoren so inaktiv wie möglich zu halten, selbst in Fällen, in denen Anweisungen in die Warteschlange gestellt werden, um sie in Interrupt-Batches abzufeuern. Kurz gesagt, verschiedene Kerne in einem Mehrprozessorsystem dürfen zeitlich relativ zueinander abweichen. Dies beeinträchtigt natürlich die gute Zeiteinhaltung und ist bisher ein ungelöstes Problem bei neueren stromsparenden Prozessorarchitekturen und den tickless-Kerneln, die ihnen eine effiziente Stromeinsparung ermöglichen. Vergleichen Sie dies mit einem tickenden Kernel (statisches Tick-Intervall), der alle Prozessorkerne kontinuierlich aufweckt, unabhängig davon, ob sie tatsächlich Arbeit erhalten oder nicht, und bei dem die Zeitmessung eine gewisse Ungenauigkeit aufweist, im Vergleich zu ticklosen Kerneln jedoch relativ zuverlässig ist.

Der StandardDie Windows-Tick-Time - also die Systemauflösung - beträgt 15,6 msbis Windows 8/2012, wo das Standardverhalten tickless ist (aber auf tickenden Kernel zurückgesetzt werden kann). Die Standard-Tickzeit von Linux hängt meines Erachtens von der Kernel-Kompilierung ab, aberdiese NischeIstweit außerhalb meiner Erfahrung(UndDieses hierauch), also sollten Sie es noch einmal überprüfen, wenn Sie davon abhängig sind. Ich glaube, Linux-Kernel werden ab 2.6.21 tickless kompiliert und können mit verschiedenen Flags kompiliert werden, die das tickless-Verhalten optimieren (und von denen ich mich nur an einige Varianten von no_hz erinnere).

So viel zu Bare-Metal-Systemen. Bei virtuellen Systemen wird es noch schlimmer, da VM- und Hypervisor-Konflikte auf unterschiedliche Weise eine genaue Zeitmessung extrem schwierig machen. Hier isteine Übersicht für VMwareUndhier ist eines für RHEL KVM. Dasselbe gilt für verteilte Systeme. Cloud-Systeme sindnoch schwierigerda wir nicht einmal annähernd in der Lage sind, tatsächliche Hypervisoren und Hardware zu sehen.

Zusammenfassend lässt sich sagen, dass die Ermittlung der genauen Zeit aus einem System ein vielschichtiges Problem ist. Wenn wir uns nun von unten nach oben und von einem übergeordneten Standpunkt aus betrachten, müssen wir Folgendes lösen: Interne Zeitsynchronisierung zwischen der Hardware und dem Kernel, Interrupt-Verarbeitung und Verzögerungen bei der Ausführung der Anweisungen, deren Zeit wir benötigen, wenn es in einer virtuellen Umgebung zu Ungenauigkeiten aufgrund der Kapselung einer zweiten Betriebssystemschicht kommt, die Synchronisierung der Zeit zwischen verteilten Systemen.

Aus diesem Grund können wir zu diesem Zeitpunkt in der Geschichte der Computertechnik mit einer x86/x64-Architektur keine Genauigkeit im Millisekundenbereich erreichen, zumindest nicht mit einem der gängigen Betriebssysteme.

Aber wie nahe können wir herankommen? Ich weiß es nicht, und es dürfte zwischen den verschiedenen Systemen sehr unterschiedlich sein. Die Ungenauigkeit der eigenen spezifischen Systeme in den Griff zu bekommen, ist eine gewaltige Aufgabe. Man muss sich nur ansehenwie Intel vorschlägt, Code-Benchmarking durchzuführenzu erkennen, dass gewöhnliche Systeme, wie die, die ich zufälligerweise verwalte, aus dieser Perspektive völlig außer Kontrolle geraten sind.

Ich denke nicht einmal daran,„Sämtliche Energieoptimierungen, Intel Hyper-Threading-Technologie, Frequenzskalierung und Turbomodus-Funktionen wurden deaktiviert.“in kritischen Systemen bastele ich viel weniger an Code-Wrappern in C herum und führe Langzeittests durch, um spätere Antworten zu erhalten. Ich versuche einfach, sie am Leben zu erhalten und so viel wie möglich über sie zu lernen, ohne sie zu sehr zu stören. Danke, Zeitstempel, ich weiß, dass ich dir nicht völlig vertrauen kann, aber ich weiß, dass du nicht allzu viele Sekunden daneben liegst. Wenn die tatsächliche Millisekundengenauigkeit wichtig wird, reicht eine Messung nicht aus, sondern es sind eine größere Anzahl von Messungen erforderlich, um das Muster zu überprüfen. Was können wir sonst noch tun?

Schließlich ist es interessant, einen Blick aufWie die Leute von Echtzeit-Betriebssystemen über Interrupt-Latenz denken. Da ist auch einsehr spannende Zeitsynchronisationsalternativein Arbeit, wo es einige interessanteStatistiken,MethodikUndweiße Papierewerden veröffentlicht. Wenn man dann noch die zukünftige Hardwarearchitektur und Kernelentwicklungen hinzurechnet, ist die Sache mit der Zeitgenauigkeit in ein paar Jahren vielleicht kein so großes Problem mehr. Das darf man zumindest hoffen.

Answer 2

Time.windows.com wird von Microsoft-Betriebssystemen nativ verwendet. Wenn Sie etwas Spezifischeres benötigen, empfehle ich die Verwendung einesNIST Internet Time Server. Sie führen sogar authentifiziertes NTP aus, falls Sie sich vor Manipulationen fürchten. Wenn das immer noch nicht ausreicht, können Sie immer noch Ihr eigenes betreiben. Es gibt eine Reihe von Anbietern, die Stratum 1- oder 2-NTP-Server verkaufen, die Sie einfach in Ihr Netzwerk einstecken können. Stratum bezieht sich auf die verschiedenen Methoden zur Zeitüberprüfung. Stratum 1 verwendet nur eine Methode (NTP, CDMA, GPS), während Stratum 2 zwei Methoden verwendet.