O Spanner Omni alcança consistência externa em ambientes autogerenciados implementando uma versão baseada em software da API TrueTime. Esse sistema depende de uma arquitetura baseada em cluster para fornecer carimbos de data/hora confiáveis, garantindo que as transações reflitam uma ordem serial estrita em toda a infraestrutura.
Para manter carimbos de data/hora e serialização precisos e consistentes, configure um servidor de tempo principal e clientes baseados em host que calculam intervalos de tempo com base na latência da rede e no desvio do relógio. Monitore a performance da implantação com métricas específicas e verifique se o hardware atende às especificações necessárias para erros de taxa de clock e sincronização de carimbos de data/hora.
Spanner Omni e TrueTime
Para oferecer a mesma consistência externa da versão gerenciada do Spanner, o Spanner Omni usa uma implementação baseada em software da API TrueTime do Google. No ambiente gerenciado do Spanner, o TrueTime alcança intervalos de incerteza estreitos usando vários servidores de tempo sincronizados com receptores GPS físicos e relógios atômicos. Como o Spanner Omni é executado em uma infraestrutura autogerenciada e não pode depender desse hardware físico, ele alcança a consistência usando uma arquitetura baseada em cluster.
Com essa implementação, todas as transações são executadas em ordem serial.
Se uma transação terminar antes de outra começar, a segunda vai refletir os efeitos da primeira. O Spanner Omni depende da seguinte sequência causal: se uma chamada para t1 = TrueTime::Now() for concluída antes do início de uma chamada para t2 = TrueTime::Now() (mesmo em máquinas diferentes), t2.latest será posterior a t1.earliest. Ao atribuir carimbos de data/hora de confirmação desses intervalos, o Spanner Omni garante que, se a transação t1 for confirmada antes do início da transação t2, os carimbos de data/hora principais vão refletir que t1 ocorreu antes de t2.
Para mais informações sobre como a versão gerenciada do Spanner usa o TrueTime, consulte TrueTime e consistência externa na documentação do Spanner.
Arquitetura do TrueTime
A arquitetura baseada em cluster usa dois componentes principais para fornecer TrueTime em toda a implantação:
Servidor de tempo: o cluster designa um servidor de banco de dados como o principal servidor de tempo. O servidor é a única fonte de verdade autorizada para toda a implantação do Spanner Omni, fornecendo a hora do relógio local de alta precisão. Para garantir a alta disponibilidade, se o servidor primário parar de responder, o cluster vai promover dinamicamente outro servidor de banco de dados para assumir essa função. O servidor de tempo é agrupado no binário do Spanner Omni, sem exigir infraestrutura separada ou dependências externas.
Cliente de tempo: um daemon em segundo plano é executado em cada máquina host na implantação. Ele consulta periodicamente o servidor de tempo principal para recuperar parâmetros de tempo atuais e os publica nos processos em execução na máquina.
O TrueTime calcula intervalos de tempo com base no desvio de relógio limitado e no tempo de retorno (RTT) da rede entre os servidores de banco de dados do Spanner Omni e o servidor de tempo principal. Todas as máquinas host na implantação precisam ter relógios locais que operem dentro de um limite conhecido no erro de taxa.
Incerteza (épsilon) e impacto na latência
O TrueTime representa o tempo como um intervalo, [earliest, latest], e não como um valor único. O TrueTime calcula o tamanho desse intervalo de incerteza com base em dois fatores:
Tempo de retorno (RTT) da rede: a latência durante a sincronização entre o cliente de tempo e o servidor de tempo principal. Os clientes de tempo localizados no mesmo data center que o servidor de tempo principal têm uma incerteza significativamente menor do que os clientes em data centers remotos.
Deriva do relógio: a deriva natural dos relógios físicos nas máquinas cliente e servidor entre as sincronizações.
A alta incerteza pode aumentar os tempos de espera de confirmação de transação. No entanto, como a replicação do Paxos também exige comunicação de rede, a incerteza do TrueTime não aumenta a latência de confirmação da transação, desde que a incerteza seja menor que a latência de ida e volta do Paxos.
Para mais detalhes, consulte Por trás do Spanner: entendendo a capacidade de serialização estrita e a consistência externa.
Requisitos de hardware
Para que o TrueTime baseado em software funcione corretamente, o hardware precisa atender aos seguintes requisitos:
- Contador de carimbo de data/hora: você precisa usar um contador de carimbo de data/hora de hardware. Em arquiteturas Linux x86, esse contador é o contador de carimbo de data/hora (TSC, na sigla em inglês).
- Erro de taxa de clock limitado: os clocks locais precisam operar dentro de um erro de taxa conhecido e limitado da frequência nominal. É possível monitorar violações
do erro de taxa de clock usando a métrica
sla_tester_violation_count. Para mais informações, consulte Observabilidade do TrueTime.
Limitações
O TrueTime não é compatível durante migrações em tempo real de máquinas virtuais (VMs) ou contêineres que executam o Spanner Omni. Há exceções para tipos de máquinas específicos e qualificados e Amazon Machine Images (AMIs) em plataformas como a Amazon Web Services (AWS). Para mais informações, consulte Requisitos do sistema do Spanner Omni.
Observabilidade
Use o painel do TrueTime no Grafana para monitorar as seguintes métricas. Use estas métricas para garantir que o TrueTime baseado em software esteja operando dentro dos parâmetros esperados:
| Métrica | Descrição | Ação recomendada |
|---|---|---|
true_time_is_available |
Verifica se a API TrueTime está disponível. | Configure alertas para qualquer indisponibilidade. Se o TrueTime não estiver disponível, o Spanner Omni também não estará. A indisponibilidade pode ser transitória ou persistente e exige investigação. |
sla_tester_violation_count |
Indica possíveis problemas de comportamento do relógio ou violações de requisitos de hardware. | Investigue para identificar a causa das violações. As possíveis causas podem ser migrações ativas, suspensões de VM ou o TSC operando fora da taxa de clock esperada. |
true_time_interval_uncertainty |
Rastreia o épsilon do intervalo do TrueTime. | Monitore essa métrica para minimizar a latência da transação. A alta incerteza aumenta os tempos de espera de confirmação, o que pode aumentar a latência geral da transação. |