Spanner Omni assure la cohérence externe dans les environnements autogérés en implémentant une version logicielle de l'API TrueTime. Ce système repose sur une architecture basée sur des clusters pour fournir des codes temporels faisant autorité, ce qui garantit que les transactions reflètent un ordre séquentiel strict dans votre infrastructure.
Pour maintenir des codes temporels et une sérialisabilité précis et cohérents, configurez un serveur de temps principal et des clients basés sur l'hôte qui calculent les intervalles de temps en fonction de la latence du réseau et de la dérive d'horloge. Surveillez les performances de votre déploiement à l'aide de métriques spécifiques et vérifiez que votre matériel sous-jacent répond aux spécifications requises pour l'erreur de fréquence d'horloge et la synchronisation des codes temporels.
Spanner Omni et TrueTime
Pour offrir la même cohérence externe que la version gérée de Spanner, Spanner Omni utilise une implémentation logicielle de l'API TrueTime de Google. Dans l'environnement Spanner géré, TrueTime permet d'obtenir des intervalles d'incertitude étroits en utilisant plusieurs serveurs temporels synchronisés avec des récepteurs GPS physiques et des horloges atomiques. Étant donné que Spanner Omni s'exécute sur une infrastructure autogérée et ne peut pas s'appuyer sur ce matériel physique, il assure la cohérence à l'aide d'une architecture basée sur les clusters.
Avec cette implémentation, toutes les transactions s'exécutent dans un ordre séquentiel.
Si une transaction se termine avant qu'une autre ne commence, la deuxième transaction reflète les effets de la première. Spanner Omni s'appuie sur la séquence causale suivante : si un appel à t1 = TrueTime::Now() se termine avant le début d'un appel à t2 = TrueTime::Now() (même sur des machines différentes), alors t2.latest est postérieur à t1.earliest. En attribuant des codes temporels de commit à partir de ces intervalles, Spanner Omni garantit que si la transaction t1 est validée avant le début de la transaction t2, les codes temporels clés reflètent le fait que t1 s'est produit avant t2.
Pour en savoir plus sur la façon dont la version gérée de Spanner utilise TrueTime, consultez TrueTime et cohérence externe dans la documentation Spanner.
Architecture TrueTime
L'architecture basée sur les clusters utilise deux composants principaux pour fournir TrueTime dans votre déploiement :
Serveur de temps : le cluster désigne un serveur de base de données comme serveur de temps principal. Le serveur est la source unique de vérité faisant autorité pour l'ensemble du déploiement Spanner Omni. Il fournit l'heure à partir de son horloge locale de haute précision. Pour garantir une haute disponibilité, si le serveur principal cesse de répondre, le cluster promeut dynamiquement un autre serveur de base de données pour assumer ce rôle. Le serveur de temps est inclus dans le binaire Spanner Omni, ce qui ne nécessite aucune infrastructure ni dépendance externe distinctes.
Client temporel : un daemon en arrière-plan s'exécute sur chaque machine hôte du déploiement. Il interroge régulièrement le serveur de temps principal pour récupérer les paramètres temporels actuels et les publie pour les processus en cours d'exécution sur la machine.
TrueTime calcule les intervalles de temps en fonction de la dérive d'horloge limitée et du délai aller-retour (DAR) du réseau entre les serveurs de base de données Spanner Omni et le serveur de temps principal. Toutes les machines hôtes du déploiement doivent disposer d'horloges locales dont l'erreur de fréquence est comprise dans une limite connue.
Incertitude (epsilon) et impact sur la latence
TrueTime représente le temps sous la forme d'un intervalle, [earliest, latest], plutôt que d'une seule valeur. TrueTime calcule la taille de cet intervalle d'incertitude en fonction de deux facteurs :
Délai aller-retour (DAR) du réseau : latence lors de la synchronisation entre le client temporel et le serveur temporel principal. Les clients temporels situés dans le même centre de données que le serveur temporel principal présentent une incertitude nettement inférieure à celle des clients situés dans des centres de données distants.
Dérive d'horloge : dérive naturelle des horloges physiques sur les machines client et serveur entre les synchronisations.
Une incertitude élevée peut augmenter les temps d'attente pour l'exécution des transactions. Toutefois, comme la réplication Paxos nécessite également une communication réseau, l'incertitude TrueTime n'augmente pas la latence de validation des transactions tant que l'incertitude est inférieure à la latence aller-retour de Paxos.
Pour en savoir plus, consultez Les rouages de Spanner : comprendre la sérialisabilité et la cohérence externe.
Configuration matérielle requise
Pour que TrueTime logiciel fonctionne correctement, le matériel sous-jacent doit répondre aux exigences suivantes :
- Compteur de code temporel : vous devez utiliser un compteur de code temporel matériel. Sur les architectures Linux x86, ce compteur est le compteur d'horodatage (TSC, Time Stamp Counter).
- Erreur de fréquence d'horloge limitée : les horloges locales doivent fonctionner avec une erreur de fréquence connue et limitée par rapport à leur fréquence nominale. Vous pouvez surveiller les cas de non-respect de l'erreur de fréquence d'horloge à l'aide de la métrique
sla_tester_violation_count. Pour en savoir plus, consultez Observabilité TrueTime.
Limites
TrueTime n'est pas compatible avec la migration à chaud des machines virtuelles (VM) ni des conteneurs exécutant Spanner Omni. Des exceptions existent pour certains types de machines et certaines Amazon Machine Images (AMI) qualifiés sur des plates-formes telles qu'Amazon Web Services (AWS). Pour en savoir plus, consultez Configuration système requise pour Spanner Omni.
Observabilité
Vous pouvez utiliser le tableau de bord TrueTime dans Grafana pour surveiller les métriques suivantes. Utilisez ces métriques pour vous assurer que TrueTime basé sur logiciel fonctionne selon les paramètres attendus :
| Métrique | Description | Action recommandée |
|---|---|---|
true_time_is_available |
Vérifie si l'API TrueTime est disponible. | Configurez des alertes pour toute indisponibilité. Si TrueTime n'est pas disponible, il est probable que Spanner Omni le soit également. L'indisponibilité peut être temporaire ou persistante, et nécessite une investigation. |
sla_tester_violation_count |
Indique des problèmes de comportement de l'horloge ou des cas de non-respect des exigences matérielles potentiels. | Menez votre enquête pour identifier la cause des cas de non-respect. Les causes possibles peuvent être des migrations à chaud, des suspensions de VM ou le fonctionnement du TSC en dehors de sa fréquence d'horloge prévue. |
true_time_interval_uncertainty |
Suit l'epsilon de l'intervalle TrueTime. | Surveillez cette métrique pour minimiser la latence des transactions. Une incertitude élevée augmente les temps d'attente des commits, ce qui peut augmenter la latence globale des transactions. |