TrueTime und externe Konsistenz

Vorschau

Dieses Produkt oder Feature ist ein Vorschauangebot, das den "Nutzungsbedingungen für Pre-GA-Angebote" im Abschnitt „Allgemeine Dienstbedingungen“ der Dienstspezifischen Nutzungsbedingungen unterliegt. Es darf nur zum Entwickeln, Testen, Erstellen von Prototypen und Vorführen von Softwareprogrammen verwendet werden. Es darf nicht für die Daten verarbeitung oder kommerzielle Zwecke verwendet werden. Pre-GA-Produkte und ‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Spanner Omni erzielt externe Konsistenz in selbstverwalteten Umgebungen durch die Implementierung einer softwarebasierten Version der TrueTime API. Dieses System basiert auf einer clusterbasierten Architektur, um autoritative Zeitstempel bereitzustellen. So wird sichergestellt, dass Transaktionen eine strikte serielle Reihenfolge in Ihrer Infrastruktur widerspiegeln.

Konfigurieren Sie einen primären Zeitserver und hostbasierte Clients, die Zeitintervalle basierend auf der Netzwerklatenz und der Uhrendrift berechnen, um genaue und konsistente Zeitstempel und Serialisierbarkeit zu gewährleisten. Überwachen Sie die Leistung Ihrer Bereitstellung anhand bestimmter Messwerte und prüfen Sie, ob Ihre zugrunde liegende Hardware die erforderlichen Spezifikationen für den Fehler der Taktrate und die Zeitstempelsynchronisierung erfüllt.

Spanner Omni und TrueTime

Um die gleiche externe Konsistenz wie die verwaltete Version von Spanner zu bieten, verwendet Spanner Omni eine softwarebasierte Implementierung der TrueTime API von Google. In der verwalteten Spanner-Umgebung erzielt TrueTime enge Unsicherheitsintervalle durch die Verwendung mehrerer Zeitserver, die mit physischen GPS-Empfängern und Atomuhren synchronisiert sind. Da Spanner Omni auf einer selbstverwalteten Infrastruktur ausgeführt wird und sich nicht auf diese physische Hardware verlassen kann, wird die Konsistenz stattdessen mithilfe einer clusterbasierten Architektur erreicht.

Bei dieser Implementierung werden alle Transaktionen in einer seriellen Reihenfolge ausgeführt. Wenn eine Transaktion abgeschlossen ist, bevor eine andere beginnt, spiegelt die zweite Transaktion die Auswirkungen der ersten wider. Spanner Omni basiert auf der folgenden kausalen Reihenfolge: Wenn ein Aufruf von t1 = TrueTime::Now() abgeschlossen ist, bevor ein Aufruf von t2 = TrueTime::Now() beginnt (auch auf verschiedenen Maschinen), dann ist t2.latest später als t1.earliest. Durch die Zuweisung von Commit-Zeitstempeln aus diesen Intervallen stellt Spanner Omni sicher, dass die wichtigsten Zeitstempel widerspiegeln, dass t1 vor t2 stattgefunden hat, wenn die Transaktion t1 vor dem Start der Transaktion t2 committet wird.

Weitere Informationen zur Verwendung von TrueTime in der verwalteten Version von Spanner finden Sie in der Spanner-Dokumentation unter TrueTime und externe Konsistenz.

TrueTime-Architektur

Die clusterbasierte Architektur verwendet zwei Kernkomponenten, um TrueTime in Ihrer Bereitstellung bereitzustellen:

• Zeitserver: Der Cluster weist einen Datenbankserver als primären Zeitserver zu. Der Server ist die autoritative Single Source of Truth für die gesamte Spanner Omni-Bereitstellung und stellt die Zeit von seiner lokalen hochpräzisen Uhr bereit. Um eine Hochverfügbarkeit zu gewährleisten, stuft der Cluster dynamisch einen anderen Datenbankserver hoch, um diese Rolle zu übernehmen, wenn der primäre Server nicht mehr reagiert. Der Zeitserver ist in die Spanner Omni-Binärdatei eingebunden und erfordert keine separate Infrastruktur oder externe Abhängigkeiten.

• Zeitclient: Auf jedem Hostcomputer in der Bereitstellung wird ein Hintergrund-Daemon ausgeführt. Er fragt regelmäßig den primären Zeitserver ab, um aktuelle Zeitparameter abzurufen, und veröffentlicht sie für die Prozesse, die auf der Maschine ausgeführt werden.

TrueTime berechnet Zeitintervalle basierend auf der begrenzten Uhrendrift und der Netzwerk-Umlaufzeit (RTT) zwischen den Spanner Omni-Datenbankservern und dem primären Zeitserver. Alle Hostmaschinen in der Bereitstellung müssen lokale Uhren haben, deren Ratenfehler innerhalb einer bekannten Grenze liegt.

Unsicherheit (Epsilon) und Auswirkungen auf die Latenz

TrueTime stellt die Zeit als Intervall ([earliest, latest]) und nicht als einzelnen Wert dar. TrueTime berechnet die Größe dieses Unsicherheitsintervalls anhand von zwei Faktoren:

• Netzwerk-Umlaufzeit (RTT): Die Latenz während der Synchronisierung zwischen dem Zeitclient und dem primären Zeitserver. Zeitclients, die sich im selben Rechenzentrum wie der primäre Zeitserver befinden, haben eine deutlich geringere Unsicherheit als Clients in Remote-Rechenzentren.

• Uhrendrift: Die natürliche Drift der physischen Uhren auf den Client- und Servermaschinen zwischen den Synchronisierungen.

Eine hohe Unsicherheit kann die Wartezeiten für das Commit von Transaktionen verlängern. Da die Paxos-Replikation jedoch auch eine Netzwerkkommunikation erfordert, erhöht die TrueTime-Unsicherheit die Latenz für das Commit von Transaktionen nicht, solange die Unsicherheit geringer ist als die Paxos-Round-Trip-Latenz.

Weitere Informationen finden Sie unter Spanner unter der Motorhaube: Verständnis von strikter Serialisierbarkeit und externer Konsistenz.

Hardwareanforderungen

Damit die softwarebasierte TrueTime ordnungsgemäß funktioniert, muss die zugrunde liegende Hardware die folgenden Anforderungen erfüllen:

• Zeitstempelzähler: Sie müssen einen Hardware-Zeitstempelzähler verwenden. Bei Linux x86-Architekturen ist dieser Zähler der Zeitstempelzähler (Time Stamp Counter, TSC).
• Begrenzter Fehler der Taktrate: Lokale Uhren müssen innerhalb eines bekannten und begrenzten Fehlers der Taktrate von ihrer nominalen Frequenz aus betrieben werden. Sie können Verstöße gegen den Fehler der Taktrate mit dem Messwert sla_tester_violation_count überwachen. Weitere Informationen finden Sie unter Beobachtbarkeit von TrueTime.

Beschränkungen

TrueTime wird während der Live-Migration von virtuellen Maschinen (VMs) oder Containern, auf denen Spanner Omni ausgeführt wird, nicht unterstützt. Ausnahmen gelten für bestimmte qualifizierte Maschinentypen und Amazon Machine Images (AMIs) auf Plattformen wie Amazon Web Services (AWS). Weitere Informationen finden Sie unter Systemanforderungen für Spanner Omni.

Beobachtbarkeit

Im TrueTime-Dashboard in Grafana können Sie die folgenden Messwerte überwachen. Mit diesen Messwerten können Sie sicherstellen, dass die softwarebasierte TrueTime innerhalb der erwarteten Parameter funktioniert:

Messwert	Beschreibung	Empfohlene Maßnahmen
true_time_is_available	Prüft, ob die TrueTime API verfügbar ist.	Konfigurieren Sie Benachrichtigungen für jede Nichtverfügbarkeit. Wenn TrueTime nicht verfügbar ist, Spanner Omni ist wahrscheinlich auch nicht verfügbar. Die Nichtverfügbarkeit kann vorübergehend oder dauerhaft sein und muss untersucht werden.
sla_tester_violation_count	Gibt potenzielle Probleme mit dem Uhrenverhalten oder Verstöße gegen die Hardware anforderungen an.	Untersuchen Sie die Ursache der Verstöße. Mögliche Ursachen sind Live-Migrationen, VM-Aussetzungen oder der TSC, der außerhalb der erwarteten Taktrate arbeitet.
true_time_interval_uncertainty	Erfasst das Epsilon des TrueTime-Intervalls.	Überwachen Sie diesen Messwert, um die Transaktionslatenz zu minimieren. Eine hohe Unsicherheit verlängert die Wartezeiten für das Commit, was die gesamte Transaktions Latenz erhöhen kann.