TrueTime und externe Konsistenz

Spanner Omni erreicht 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 strenge serielle Reihenfolge in Ihrer Infrastruktur widerspiegeln.

Um genaue und einheitliche Zeitstempel und Serialisierbarkeit zu gewährleisten, konfigurieren Sie einen primären Zeitserver und hostbasierte Clients, die Zeitintervalle basierend auf Netzwerklatenz und Taktverschiebung berechnen. Überwachen Sie die Leistung Ihrer Bereitstellung anhand bestimmter Messwerte und prüfen Sie, ob die zugrunde liegende Hardware die erforderlichen Spezifikationen für Taktfrequenzfehler und Zeitstempelsynchronisierung erfüllt.

Spanner Omni und TrueTime

Um dieselbe 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 werden mit TrueTime enge Unsicherheitsintervalle erreicht, indem mehrere Zeitserver verwendet werden, die mit physischen GPS-Empfängern und Atomuhren synchronisiert sind. Da Spanner Omni auf selbstverwalteter Infrastruktur ausgeführt wird und sich nicht auf diese physische Hardware verlassen kann, wird die Konsistenz stattdessen durch eine clusterbasierte Architektur erreicht.

Bei dieser Implementierung werden alle Transaktionen in serieller Reihenfolge ausgeführt. Wenn eine Transaktion abgeschlossen ist, bevor eine andere beginnt, werden die Auswirkungen der ersten Transaktion in der zweiten berücksichtigt. Spanner Omni basiert auf der folgenden kausalen Sequenzierung: Wenn ein Aufruf von t1 = TrueTime::Now() abgeschlossen ist, bevor ein Aufruf von t2 = TrueTime::Now() beginnt (auch auf verschiedenen Computern), 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 für die Transaktion t1 ein Commit erfolgt, bevor die Transaktion t2 beginnt.

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: Im Cluster wird ein Datenbankserver als primärer Zeitserver festgelegt. Der Server ist die maßgebliche 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, wird bei einem Ausfall des primären Servers dynamisch ein anderer Datenbankserver im Cluster zum primären Server hochgestuft. Der Zeitserver ist im binären Spanner Omni-Paket enthalten. Es sind keine separate Infrastruktur oder externen Abhängigkeiten erforderlich.

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

TrueTime berechnet Zeitintervalle basierend auf der begrenzten Taktabweichung und der Netzwerk-Umlaufzeit (RTT) zwischen den Spanner Omni-Datenbankservern und dem primären Zeitserver. Alle Hostcomputer 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. Bei Zeitclients, die sich im selben Rechenzentrum wie der primäre Zeitserver befinden, ist die Unsicherheit deutlich geringer als bei Clients in Remote-Rechenzentren.

  • Uhrzeitabweichung: Die natürliche Abweichung der physischen Uhren auf den Client- und Servercomputern zwischen den Synchronisierungen.

Bei hoher Unsicherheit kann sich die Wartezeit für die Transaktionsbestätigung verlängern. Da die Paxos-Replikation jedoch auch Netzwerkkommunikation erfordert, erhöht die TrueTime-Unsicherheit die Latenz für die Transaktionsbestätigung 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 softwarebasiertes TrueTime richtig funktioniert, muss die zugrunde liegende Hardware die folgenden Anforderungen erfüllen:

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

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. Es gibt Ausnahmen 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

Mit dem TrueTime-Dashboard in Grafana können Sie die folgenden Messwerte überwachen. Mit diesen Messwerten können Sie prüfen, ob die softwarebasierte TrueTime-Lösung innerhalb der erwarteten Parameter funktioniert:

Messwert Beschreibung Empfohlene Maßnahmen
true_time_is_available Prüft, ob die TrueTime API verfügbar ist. Benachrichtigungen für Ausfälle konfigurieren Wenn TrueTime nicht verfügbar ist, ist Spanner Omni wahrscheinlich auch nicht verfügbar. Die Nichtverfügbarkeit kann vorübergehend oder dauerhaft sein und muss untersucht werden.
sla_tester_violation_count Weist auf potenzielle Probleme mit dem Taktverhalten oder Verstöße gegen Hardwareanforderungen hin. Ermitteln Sie die Ursache der Verstöße. Mögliche Ursachen sind Live-Migrationen, VM-Unterbrechungen oder der TSC, der außerhalb seiner erwarteten Taktfrequenz arbeitet.
true_time_interval_uncertainty Erfasst das Epsilon des TrueTime-Intervalls. Behalten Sie diesen Messwert im Blick, um die Transaktionslatenz zu minimieren. Eine hohe Unsicherheit erhöht die Commit-Wartezeiten, was die Latenz der gesamten Transaktion erhöhen kann.