View a markdown version of this page

Gestion de la résolution DNS pour les points de terminaison du cluster - Amazon Timestream
Comprendre la mise en cache DNSSolution 1 : configurer le TTL DNS de la JVM (applications Java)Solution 2 : résolution directe via des serveurs de noms faisant autoritéGestion des modifications de l'adresse IP des nœudsBonnes pratiques

Pour des fonctionnalités similaires à celles d'Amazon Timestream pour, pensez à Amazon Timestream LiveAnalytics pour InfluxDB. Il permet une ingestion simplifiée des données et des temps de réponse aux requêtes à un chiffre en millisecondes pour des analyses en temps réel. Pour en savoir plus, cliquez ici.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Gestion de la résolution DNS pour les points de terminaison du cluster

Timestream pour InfluxDB pour InfluxDB 3 Les clusters multi-nœuds utilisent la distribution du trafic basée sur le DNS pour équilibrer les connexions entre les nœuds. En cas de basculement ou de remplacement de nœuds, les enregistrements DNS sont automatiquement mis à jour pour indiquer les instances disponibles. Pour que votre application puisse détecter ces modifications et maintenir une distribution optimale du trafic, il est essentiel de configurer correctement la résolution DNS.

Comprendre la mise en cache DNS

De nombreux environnements de programmation mettent en cache les recherches DNS pour améliorer les performances. Toutefois, cette mise en cache peut empêcher votre application de découvrir des adresses IP mises à jour après un basculement ou de distribuer des connexions sur plusieurs nœuds de cluster. L'impact varie en fonction de la langue et de l'environnement d'exécution :

  • Applications basées sur Java/JVM — La JVM met en cache les recherches DNS pour une configuration (TTL). time-to-live Certaines configurations sont mises en cache indéfiniment jusqu'au redémarrage de la JVM.

  • Autres langages : Python, Go, Node.js et d'autres environnements d'exécution reposent généralement sur la résolution DNS du système d'exploitation et peuvent ne pas présenter le même comportement de mise en cache.

Solution 1 : configurer le TTL DNS de la JVM (applications Java)

Pour les applications Java se connectant à Timestream pour InfluxDB pour les points de terminaison du cluster InfluxDB 3, définissez le TTL du cache DNS JVM sur zéro. Cela garantit que chaque connexion déclenche une nouvelle recherche DNS, ce qui permet une distribution correcte du trafic et une détection immédiate des basculements.

Vérifiez votre paramètre TTL actuel :

String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");

Configurez le TTL à l'aide de l'une des méthodes suivantes :

  • Configuration globale — Paramétrée networkaddress.cache.ttl dans $JAVA_HOME/jre/lib/security/java.security :

    networkaddress.cache.ttl=0

  • Configuration spécifique à l'application : définissez la propriété dans le code d'initialisation de votre application avant d'établir des connexions réseau :

    java.security.Security.setProperty("networkaddress.cache.ttl", "0");

  • Argument JVM — Passez en tant que propriété système lors du démarrage de votre application :

    java -Dsun.net.inetaddr.ttl=0 -jar your-application.jar
Note

Pour les points de terminaison hors cluster ou les AWS ressources générales, un TTL de 60 secondes est généralement suffisant. La recommandation zéro TTL est spécifique aux points de terminaison du cluster InfluxDB 3 où la distribution du trafic et la détection rapide des basculements sont essentielles.

Solution 2 : résolution directe via des serveurs de noms faisant autorité

Si la configuration TTL est insuffisante, par exemple en raison d'une mise en cache intermédiaire au niveau du système d'exploitation, ou si votre langage de programmation ne présente aucun problème de mise en cache DNS, vous pouvez forcer une nouvelle résolution DNS en interrogeant directement les serveurs de noms faisant autorité. Utilisez cette approche uniquement lorsque la configuration TTL standard ne résout pas le problème.

Flux de travail de résolution directe

  1. Identifiez le serveur de noms faisant autorité pour le point de terminaison de votre cluster :

    dig <cluster-endpoint> NS

    Dans AUTHORITY SECTION la sortie, notez le serveur de noms indiqué après. IN SOA Par exemple : ns-1458.awsdns-54.org.

  2. Interrogez directement le serveur de noms faisant autorité pour contourner les caches :

    dig @ns-1458.awsdns-54.org <cluster-endpoint>

    Cela renvoie les adresses IP actuelles du point de terminaison, reflétant la distribution réelle du trafic basée sur le DNS.

  3. Utilisez la ou les adresses IP résolues pour les connexions à vos applications. Répétez cette résolution régulièrement ou lorsque des erreurs de connexion se produisent pour actualiser les adresses.

Exemple :

# Find authoritative nameserver
dig my-cluster.timestream-influxdb.us-east-1.amazonaws.com NS

# Resolve using authoritative nameserver
dig @ns-1458.awsdns-54.org my-cluster.timestream-influxdb.us-east-1.amazonaws.com

# Use returned IP addresses in your application

Gestion des modifications de l'adresse IP des nœuds

Important

Les adresses IP des nœuds ne sont pas statiques. Ils changent lors des basculements, des redémarrages de nœuds, des opérations de maintenance et de la mise à l'échelle du cluster. Ne mettez jamais en cache indéfiniment les adresses IP résolues.

Mettez en œuvre les pratiques suivantes pour gérer les modifications de propriété intellectuelle :

  • Résolution périodique : rerésolvez les points de terminaison toutes les 30 à 60 secondes à l'aide d'une tâche en arrière-plan. Comparez les nouvelles adresses IP aux valeurs mises en cache et mettez à jour votre pool de connexions en conséquence.

  • Résolution provoquée par des erreurs : en cas d'échec d'une connexion (délai d'expiration, connexion refusée, réinitialisation), réessayez immédiatement de résoudre le problème du point de terminaison et réessayez avec les adresses IP mises à jour.

  • Évacuation progressive des connexions : lorsqu'une adresse IP ne figure plus dans le jeu d'enregistrements DNS, autorisez les demandes en cours de traitement mais arrêtez de créer de nouvelles connexions à cette adresse IP.

  • Création d'une nouvelle connexion — Après la rerésolution, créez de nouvelles connexions à l'aide d'adresses IP mises à jour. Les connexions existantes épinglées aux anciennes IPs ne bénéficieront pas de la rerésolution.

Bonnes pratiques

  • Commencez par la configuration TTL : pour les applications Java, essayez toujours d'networkaddress.cache.ttl=0abord de configurer. Il s'agit de la solution la plus simple et la plus efficace.

  • Utilisez la résolution directe avec parcimonie : utilisez uniquement des requêtes de serveur de noms faisant autorité lorsque la configuration TTL est insuffisante ou lorsqu'il s'agit d'une mise en cache intermédiaire persistante.

  • Automatisez la découverte des serveurs de noms : ne codez pas en dur les adresses des serveurs de noms. Découvrez-les de manière dynamique, car les attributions des serveurs de noms peuvent changer.

  • S'applique uniquement aux points de terminaison du cluster : ces techniques concernent les points de terminaison au niveau du cluster (écriture et lecture) qui utilisent la distribution basée sur le DNS. Les points de terminaison spécifiques aux nœuds qui ciblent directement des nœuds individuels ne nécessitent pas cette configuration.

  • Testez votre implémentation : vérifiez que votre application répartit correctement les connexions entre plusieurs nœuds et rétablit les défaillances de nœuds simulées.