TrueTime et cohérence externe

Aperçu

Ce produit ou cette fonctionnalité est une offre en preview soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Il ne peut être utilisé qu'à des fins de développement, de test, de prototypage et de démonstration de programmes logiciels. Il ne peut être utilisé à des fins de traitement de données ni à des fins commerciales. Les produits et fonctionnalités de pré-DG sont proposés "en l'état" et peuvent présenter une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

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 s'appuie sur une architecture basée sur un cluster pour fournir des codes temporels faisant autorité, garantissant que les transactions reflètent un ordre sériel 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 de l'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 fournir 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 atteint des intervalles d'incertitude étroits en utilisant plusieurs serveurs de temps 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 un cluster.

Avec cette implémentation, toutes les transactions s'exécutent dans un ordre sériel. 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 s'assure que si la transaction t1 est validée avant le début de la transaction t2, les codes temporels clés reflètent 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 un cluster 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 seule source de vérité faisant autorité pour l'ensemble du déploiement Spanner Omni, fournissant 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 regroupé dans le binaire Spanner Omni, ce qui ne nécessite aucune infrastructure distincte ni aucune dépendance externe.

• Client de temps : 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 de l'heure actuelle et les publie dans 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 fonctionnant dans une limite connue de leur erreur de fréquence.

Impact de l'incertitude (epsilon) et de la latence

TrueTime représente le temps sous forme d'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 de temps et le serveur de temps principal. Les clients de temps situés dans le même centre de données que le serveur de temps principal présentent une incertitude nettement inférieure à celle des clients situés dans des centres de données distants.

• Dérive de l'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 de validation 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 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 basé sur un 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 de code temporel (TSC).
• Erreur de fréquence d'horloge limitée : les horloges locales doivent fonctionner dans une erreur de fréquence connue et limitée par rapport à leur fréquence nominale. Vous pouvez surveiller les violations 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 lors des migrations à chaud de machines virtuelles (VM) ou de conteneurs exécutant Spanner Omni. Des exceptions existent pour des types de machines spécifiques et qualifiés, ainsi que pour des images Amazon Machine Images (AMI) 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 un logiciel fonctionne dans 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 en cas d'indisponibilité. Si TrueTime n'est pas disponible, il est probable que Spanner Omni ne le soit pas non plus. L' indisponibilité peut être temporaire ou persistante, et nécessite une investigation.
sla_tester_violation_count	Indique des problèmes potentiels de comportement de l'horloge ou des violations des exigences matérielles.	Effectuez une investigation pour identifier la cause des violations. 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 limite attendue.
true_time_interval_uncertainty	Suit l'epsilon de l' intervalle TrueTime.	Surveillez cette métrique pour réduire la latence des transactions. Une incertitude élevée augmente les temps d'attente de validation, ce qui peut augmenter la latence globale des transactions.