O Spanner Omni alcança 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 autorizados, garantindo que as transações reflitam uma ordem serial estrita em toda a infraestrutura.
Para manter carimbos de data/hora e capacidade de serialização precisos e consistentes, configure um servidor de horário 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 usando métricas específicas e verifique se o hardware subjacente atende às especificações necessárias para erro de taxa de clock e sincronização de carimbo de data/hora.
Spanner Omni e TrueTime
Para fornecer a mesma consistência externa que a 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 horário sincronizados com receptores de 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 que outra comece, a segunda transação 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 o TrueTime em toda a implantação:
Servidor de horário: o cluster designa um servidor de banco de dados como o servidor de horário principal. O servidor é a única fonte de verdade autorizada para toda a implantação do Spanner Omni, fornecendo o horário do relógio local de alta precisão. Para garantir a alta disponibilidade, se o servidor principal parar de responder, o cluster vai promover dinamicamente outro servidor de banco de dados para assumir esse papel. O servidor de horário é agrupado no binário do Spanner Omni, sem exigir infraestrutura separada ou dependências externas.
Cliente de horário: um daemon em segundo plano é executado em cada máquina host na implantação. Ele consulta periodicamente o servidor de horário principal para recuperar os parâmetros de horário 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 horário principal. Todas as máquinas host na implantação precisam ter relógios locais que operem dentro de um limite conhecido na taxa de erro.
Incerteza (épsilon) e impacto de latência
O TrueTime representa o tempo como um intervalo, [earliest, latest], em vez de um único valor. 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 horário e o servidor de horário principal. Os clientes de horário localizados no mesmo data center que o servidor de horário principal têm uma incerteza significativamente menor do que os clientes em data centers remotos.
Desvio do relógio: o desvio 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 da 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 retorno 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 subjacente precisa atender aos seguintes requisitos:
- Contador de carimbo de data/hora: é necessário usar um contador de carimbo de data/hora de hardware. Em arquiteturas Linux x86, esse contador é o Time Stamp Counter (TSC).
- Erro de taxa de clock limitado: os relógios 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 com 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áquina e Amazon Machine Images (AMIs) específicos e qualificados em plataformas como a Amazon Web Services (AWS). Para mais informações, consulte Requisitos do sistema do Spanner Omni.
Observabilidade
É possível usar o painel do TrueTime no Grafana para monitorar as seguintes métricas. Use essas 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, é provável que o Spanner Omni também não esteja. 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 em tempo real, suspensões de VMs ou o TSC operando fora da taxa de clock esperada. |
true_time_interval_uncertainty |
Acompanha o épsilon do intervalo 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. |