Spanner Omni raggiunge la coerenza esterna negli ambienti autogestiti implementando una versione basata su software dell'API TrueTime. Questo sistema si basa su un'architettura basata su cluster per fornire timestamp autorevoli, garantendo che le transazioni riflettano un ordine seriale rigoroso nella tua infrastruttura.
Per mantenere timestamp e serializzabilità accurati e coerenti, configura un server di riferimento per l'ora e client basati sull'host che calcolano gli intervalli di tempo in base alla latenza di rete e alla deriva dell'orologio. Monitora le prestazioni del deployment tramite metriche specifiche e verifica che l'hardware sottostante soddisfi le specifiche richieste per l'errore di frequenza di clock e la sincronizzazione dei timestamp.
Spanner Omni e TrueTime
Per fornire la stessa coerenza esterna della versione gestita di Spanner, Spanner Omni utilizza un'implementazione basata su software dell'API TrueTime di Google. Nell'ambiente Spanner gestito, TrueTime raggiunge intervalli di incertezza ristretti utilizzando più server di sincronizzazione dell'ora con ricevitori GPS fisici e orologi atomici. Poiché Spanner Omni viene eseguito su un'infrastruttura autogestita e non può fare affidamento su questo hardware fisico, ottiene la coerenza utilizzando un'architettura basata su cluster.
Con questa implementazione, tutte le transazioni vengono eseguite in ordine seriale.
Se una transazione termina prima dell'inizio di un'altra, la seconda transazione
riflette gli effetti della prima. Spanner Omni si basa sulla seguente sequenza causale: se una chiamata a t1 = TrueTime::Now() viene completata prima dell'inizio di una chiamata a t2 = TrueTime::Now() (anche su macchine diverse), allora t2.latest è successivo a t1.earliest. Assegnando i timestamp di commit
di questi intervalli, Spanner Omni garantisce che se la transazione
t1 viene eseguita prima dell'inizio della transazione t2, i timestamp chiave riflettono che t1
si è verificato prima di t2.
Per saperne di più su come la versione gestita di Spanner utilizza TrueTime, consulta TrueTime e coerenza esterna nella documentazione di Spanner.
Architettura TrueTime
L'architettura basata su cluster utilizza due componenti principali per fornire TrueTime nel deployment:
Server di sincronizzazione dell'ora: il cluster designa un server di database come server di sincronizzazione dell'ora principale. Il server è l'unica fonte attendibile per l'intero deployment di Spanner Omni, fornendo l'ora dal suo orologio locale di alta precisione. Per garantire l'alta affidabilità, se il server principale smette di rispondere, il cluster promuove dinamicamente un altro server di database per assumere questo ruolo. Il server di sincronizzazione dell'ora è incluso nel binario Spanner Omni, senza richiedere infrastrutture separate o dipendenze esterne.
Client ora: un daemon in background viene eseguito su ogni macchina host nel deployment. Esegue periodicamente query sul server di sincronizzazione dell'ora principale per recuperare i parametri dell'ora corrente e li pubblica nei processi in esecuzione sulla macchina.
TrueTime calcola gli intervalli di tempo in base alla deriva dell'orologio limitata e al tempo di round trip (RTT) della rete tra i server di database Spanner Omni e il server di sincronizzazione dell'ora principale. Tutte le macchine host nel deployment devono avere orologi locali che funzionano entro un limite noto del loro errore di velocità.
Incertezza (epsilon) e impatto della latenza
TrueTime rappresenta il tempo come un intervallo, [earliest, latest], anziché un
valore singolo. TrueTime calcola la dimensione di questo intervallo di incertezza in base a
due fattori:
Tempo di round trip (RTT) della rete: la latenza durante la sincronizzazione tra il client di tempo e il server di tempo principale. I client temporali che si trovano nello stesso data center del server temporale primario presentano un'incertezza significativamente inferiore rispetto ai client che si trovano in data center remoti.
Deriva dell'orologio: la deriva naturale degli orologi fisici sulle macchine client e server tra le sincronizzazioni.
Un'elevata incertezza può aumentare i tempi di attesa per il commit delle transazioni. Tuttavia, poiché la replica Paxos richiede anche la comunicazione di rete, l'incertezza di TrueTime non aumenta la latenza di commit delle transazioni finché l'incertezza è inferiore alla latenza round trip di Paxos.
Per maggiori dettagli, vedi Spanner under the hood: Understanding strict serializability and external consistency.
Requisiti hardware
Affinché TrueTime basato su software funzioni correttamente, l'hardware sottostante deve soddisfare i seguenti requisiti:
- Contatore timestamp: devi utilizzare un contatore timestamp hardware. Sulle architetture x86 Linux, questo contatore è il Time Stamp Counter (TSC).
- Errore di frequenza di clock limitata: gli orologi locali devono funzionare entro un errore di frequenza noto e limitato rispetto alla frequenza nominale. Puoi monitorare le violazioni
dell'errore di frequenza di clock utilizzando la metrica
sla_tester_violation_count. Per saperne di più, consulta Osservabilità di TrueTime.
Limitazioni
TrueTime non è supportato durante le migrazioni live di macchine virtuali (VM) o container che eseguono Spanner Omni. Esistono eccezioni per tipi di macchine e Amazon Machine Images (AMI) specifici e qualificati su piattaforme come Amazon Web Services (AWS). Per saperne di più, consulta la pagina Requisiti di sistema di Spanner Omni.
Osservabilità
Puoi utilizzare la dashboard TrueTime in Grafana per monitorare le seguenti metriche. Utilizza queste metriche per assicurarti che TrueTime basato su software funzioni entro i parametri previsti:
| Metrica | Descrizione | Azione consigliata |
|---|---|---|
true_time_is_available |
Controlla se l'API TrueTime è disponibile. | Configura gli avvisi per qualsiasi indisponibilità. Se TrueTime non è disponibile, è probabile che anche Spanner Omni non sia disponibile. L'indisponibilità può essere temporanea o persistente e richiede un'indagine. |
sla_tester_violation_count |
Indica potenziali problemi di comportamento dell'orologio o violazioni dei requisiti hardware. | Esegui un'indagine per identificare la causa delle violazioni. Le cause possibili potrebbero essere migrazioni live, sospensioni di VM o il funzionamento di TSC al di fuori della frequenza di clock prevista. |
true_time_interval_uncertainty |
Monitora l'epsilon dell'intervallo TrueTime. | Monitora questa metrica per ridurre al minimo la latenza delle transazioni. Un'elevata incertezza aumenta i tempi di attesa del commit, il che può aumentare la latenza complessiva delle transazioni. |