TrueTime y coherencia externa

Vista previa

Este producto o esta función es una oferta de vista previa sujeta a las "Condiciones de la oferta de la fase previa a la DG" en la sección Condiciones del servicio generales de las Condiciones específicas del servicio y solo se puede usar para desarrollar, probar, crear prototipos y demostrar programas de software. No se puede usar para el procesamiento de datos ni para fines comerciales. Los productos y las funciones de la fase previa a la DG están disponibles "sin modificaciones" y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Spanner Omni logra la coherencia externa en entornos autoadministrados mediante la implementación de 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 la infraestructura.

Para mantener marcas de tiempo y serialización precisas y coherentes, configura un servidor de hora principal y clientes basados en el host que calculen los intervalos de tiempo en función de 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 de Spanner administrado, TrueTime logra intervalos de incertidumbre estrechos mediante el uso de varios servidores de hora sincronizados con receptores GPS físicos y relojes atómicos. Debido a que Spanner Omni se ejecuta en una infraestructura autoadministrada y no puede depender de este hardware físico, logra la coherencia mediante 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 transacción refleja 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 máquinas diferentes), 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 clave reflejen que t1 ocurrió antes que 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 la 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, ya que proporciona la hora de 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 esta función. El servidor de hora se incluye en el objeto binario de Spanner Omni, por lo que no requiere infraestructura independiente ni dependencias externas.

• Cliente de hora: Un daemon en segundo plano se ejecuta 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 del reloj delimitada y el tiempo de ida y vuelta (RTT) de la red entre los servidores de 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 operen dentro de un límite conocido en su error de frecuencia.

Incertidumbre (épsilon) y efecto de 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: La latencia durante la sincronización entre el cliente de hora y el servidor de hora principal. Los clientes de hora ubicados en el mismo centro de datos que el servidor de hora principal experimentan una incertidumbre significativamente menor que los clientes en centros de datos remotos.

• Desviación del reloj: La desviación natural de los relojes físicos en las máquinas cliente y servidor entre las sincronizaciones.

La alta incertidumbre puede aumentar los tiempos de espera de confirmación de la transacción. Sin embargo, debido a 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 que 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 de reloj delimitado: Los relojes locales deben operar dentro de un error de frecuencia conocido y delimitado de su frecuencia nominal. Puedes supervisar las infracciones 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) o 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 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 falta de disponibilidad puede ser transitoria o persistente, y requiere investigación.
sla_tester_violation_count	Indica posibles problemas de comportamiento del reloj o infracciones de los requisitos de hardware.	Investiga para identificar la causa de las infracciones. Las posibles causas pueden ser migraciones en vivo, suspensiones de VM o el TSC que opera fuera de su frecuencia de reloj delimitada esperada.
true_time_interval_uncertainty	Realiza un seguimiento del épsilon del intervalo de TrueTime.	Supervisa esta métrica para minimizar la latencia de la transacción. La alta incertidumbre aumenta los tiempos de espera de confirmación, lo que puede aumentar la latencia general de la transacción.