Spanner Omni logra la coherencia externa en entornos autoadministrados implementando una versión basada en software de la API de TrueTime. Este sistema se basa en una arquitectura basada en clústeres para proporcionar marcas de tiempo autorizadas, lo que garantiza que las transacciones reflejen un orden serial estricto en toda tu infraestructura.
Para mantener marcas de tiempo y serialización precisas y coherentes, configura un servidor de tiempo principal y clientes basados en el host que calculen los intervalos de tiempo según la latencia de la red y la desviación del reloj. Supervisa el rendimiento de tu implementación a través de métricas específicas y verifica que el hardware subyacente cumpla con las especificaciones requeridas para el error de frecuencia de reloj y la sincronización de marcas de tiempo.
Spanner Omni y TrueTime
Para proporcionar la misma coherencia externa que la versión administrada de Spanner, Spanner Omni usa una implementación basada en software de la API de TrueTime de Google. En el entorno administrado de Spanner, TrueTime logra intervalos de incertidumbre estrechos con varios servidores de tiempo sincronizados con relojes atómicos y receptores GPS físicos. Dado que Spanner Omni se ejecuta en una infraestructura autoadministrada y no puede depender de este hardware físico, logra la coherencia con una arquitectura basada en clústeres.
Con esta implementación, todas las transacciones se ejecutan en orden serial.
Si una transacción finaliza antes de que comience otra, la segunda reflejará los efectos de la primera. Spanner Omni se basa en la siguiente secuencia causal: si una llamada a t1 = TrueTime::Now() se completa antes de que comience una llamada a t2 = TrueTime::Now() (incluso en diferentes máquinas), entonces t2.latest es posterior a t1.earliest. Al asignar marcas de tiempo de confirmación de estos intervalos, Spanner Omni garantiza que, si la transacción t1 se confirma antes de que comience la transacción t2, las marcas de tiempo de las claves reflejen que t1 ocurrió antes de t2.
Para obtener más información sobre cómo la versión administrada de Spanner usa TrueTime, consulta TrueTime y coherencia externa en la documentación de Spanner.
Arquitectura de TrueTime
La arquitectura basada en clústeres usa dos componentes principales para proporcionar TrueTime en toda tu implementación:
Servidor de hora: El clúster designa un servidor de base de datos como el servidor de hora principal. El servidor es la única fuente de información autorizada para toda la implementación de Spanner Omni, y proporciona la hora desde su reloj local de alta precisión. Para garantizar la alta disponibilidad, si el servidor principal deja de responder, el clúster promueve de forma dinámica otro servidor de base de datos para que asuma este rol. El servidor de hora se incluye en el objeto binario de Spanner Omni, por lo que no se requiere infraestructura independiente ni dependencias externas.
Cliente de tiempo: Se ejecuta un daemon en segundo plano en cada máquina anfitrión de la implementación. Consulta periódicamente el servidor de hora principal para recuperar los parámetros de hora actuales y los publica en los procesos que se ejecutan en la máquina.
TrueTime calcula los intervalos de tiempo en función de la desviación limitada del reloj y el tiempo de ida y vuelta (RTT) de la red entre los servidores de la base de datos de Spanner Omni y el servidor de hora principal. Todas las máquinas host de la implementación deben tener relojes locales que funcionen dentro de un límite conocido en su error de velocidad.
Incertidumbre (épsilon) y el impacto en la latencia
TrueTime representa el tiempo como un intervalo, [earliest, latest], en lugar de un solo valor. TrueTime calcula el tamaño de este intervalo de incertidumbre en función de dos factores:
Tiempo de ida y vuelta (RTT) de la red: Es la latencia durante la sincronización entre el cliente de tiempo y el servidor de tiempo principal. Los clientes de tiempo ubicados en el mismo centro de datos que el servidor de tiempo principal experimentan una incertidumbre significativamente menor que los clientes en centros de datos remotos.
Deriva del reloj: Es la deriva natural de los relojes físicos en las máquinas cliente y servidor entre las sincronizaciones.
Una alta incertidumbre puede aumentar los tiempos de espera de la confirmación de la transacción. Sin embargo, dado que la replicación de Paxos también requiere comunicación de red, la incertidumbre de TrueTime no aumenta la latencia de confirmación de la transacción, siempre y cuando la incertidumbre sea menor que la latencia de ida y vuelta de Paxos.
Para obtener más detalles, consulta Spanner under the hood: Understanding strict serializability and external consistency.
Requisitos de hardware
Para que TrueTime basado en software funcione correctamente, el hardware subyacente debe cumplir con los siguientes requisitos:
- Contador de marcas de tiempo: Debes usar un contador de marcas de tiempo de hardware. En las arquitecturas x86 de Linux, este contador es el contador de marcas de tiempo (TSC).
- Error de frecuencia acotado: Los relojes locales deben funcionar dentro de un error de frecuencia conocido y acotado a partir de su frecuencia nominal. Puedes supervisar los incumplimientos del error de frecuencia de reloj con la métrica
sla_tester_violation_count. Para obtener más información, consulta Observabilidad de TrueTime.
Limitaciones
TrueTime no es compatible durante las migraciones en vivo de máquinas virtuales (VMs) ni de contenedores que ejecutan Spanner Omni. Existen excepciones para tipos de máquinas específicos y calificados, y para imágenes de máquina de Amazon (AMI) en plataformas como Amazon Web Services (AWS). Para obtener más información, consulta los requisitos del sistema de Spanner Omni.
Observabilidad
Puedes usar el panel de TrueTime en Grafana para supervisar las siguientes métricas. Usa estas métricas para asegurarte de que TrueTime basado en software funcione dentro de los parámetros esperados:
| Métrica | Descripción | Acción recomendada |
|---|---|---|
true_time_is_available |
Comprueba si la API de TrueTime está disponible. | Configura alertas para cualquier falta de disponibilidad. Si TrueTime no está disponible, es probable que Spanner Omni tampoco lo esté. La no disponibilidad puede ser transitoria o persistente, y requiere investigación. |
sla_tester_violation_count |
Indica posibles problemas de comportamiento del reloj o incumplimientos de requisitos de hardware. | Investiga para identificar la causa de los incumplimientos. Las posibles causas pueden ser migraciones en vivo, suspensiones de la VM o el TSC que funciona fuera de su frecuencia de reloj esperada. |
true_time_interval_uncertainty |
Realiza un seguimiento del épsilon del intervalo de TrueTime. | Supervisa esta métrica para minimizar la latencia de las transacciones. La alta incertidumbre aumenta los tiempos de espera de confirmación, lo que puede aumentar la latencia general de las transacciones. |