View a markdown version of this page

Administrar la resolución de DNS para los puntos finales del clúster - Amazon Timestream
Entender el almacenamiento en caché de DNSSolución 1: configurar el TTL del DNS de la JVM (aplicaciones Java)Solución 2: resolución directa mediante servidores de nombres acreditadosGestionar los cambios de IP de los nodosPrácticas recomendadas

Para obtener capacidades similares a las de Amazon Timestream, considere Amazon Timestream LiveAnalytics para InfluxDB. Ofrece una ingesta de datos simplificada y tiempos de respuesta a las consultas en milisegundos de un solo dígito para realizar análisis en tiempo real. Obtenga más información aquí.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Administrar la resolución de DNS para los puntos finales del clúster

Timestream para InfluxDB: los clústeres multinodo de InfluxDB 3 utilizan una distribución del tráfico basada en DNS para equilibrar las conexiones entre los nodos. Cuando se produce una conmutación por error o se sustituyen los nodos, los registros de DNS se actualizan automáticamente para indicar las instancias disponibles. Para garantizar que su aplicación pueda detectar estos cambios y mantener una distribución óptima del tráfico, es esencial configurar correctamente la resolución de DNS.

Entender el almacenamiento en caché de DNS

Muchos entornos de programación almacenan en caché las búsquedas de DNS para mejorar el rendimiento. Sin embargo, este almacenamiento en caché puede impedir que la aplicación descubra las direcciones IP actualizadas tras una conmutación por error o que distribuya las conexiones entre varios nodos del clúster. El impacto varía según el idioma y el tiempo de ejecución:

  • Aplicaciones basadas en Java/JVM: la JVM almacena en caché las búsquedas de DNS para un formato configurable (TTL). time-to-live Algunas configuraciones almacenan en caché indefinidamente hasta que la JVM se reinicie.

  • Otros lenguajes: Python, Go, Node.js y otros tiempos de ejecución suelen depender de la resolución DNS del sistema operativo y es posible que no muestren el mismo comportamiento de almacenamiento en caché.

Solución 1: configurar el TTL del DNS de la JVM (aplicaciones Java)

Para las aplicaciones Java que se conectan a Timestream para InfluxDB para los puntos finales del clúster InfluxDB 3, establezca el TTL de la caché DNS de la JVM en cero. Esto garantiza que cada conexión active una nueva búsqueda de DNS, lo que permite una distribución adecuada del tráfico y una detección inmediata de la conmutación por error.

Comprueba tu configuración de TTL actual:

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

Configure el TTL mediante uno de estos métodos:

  • Configuración global: establecida networkaddress.cache.ttl en$JAVA_HOME/jre/lib/security/java.security:

    networkaddress.cache.ttl=0

  • Configuración específica de la aplicación: defina la propiedad en el código de inicialización de la aplicación antes de establecer las conexiones de red:

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

  • Argumento de JVM: se transmite como propiedad del sistema al iniciar la aplicación:

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

Para los puntos finales que no son de clúster o AWS los recursos generales, un TTL de 60 segundos suele ser suficiente. La recomendación de cero TTL es específica para los puntos finales de clúster de InfluxDB 3, donde la distribución del tráfico y la detección rápida de las conmutaciones por error son fundamentales.

Solución 2: resolución directa mediante servidores de nombres acreditados

Si la configuración del TTL no es suficiente (por ejemplo, debido al almacenamiento en caché de nivel intermedio del sistema operativo o si tu lenguaje de programación no presenta problemas de almacenamiento en caché del DNS), puedes forzar una nueva resolución del DNS consultando directamente a los servidores de nombres autorizados. Usa este enfoque solo cuando la configuración TTL estándar no resuelva el problema.

Flujo de trabajo de resolución directa

  1. Identifique el servidor de nombres autorizado para el punto final de su clúster:

    dig <cluster-endpoint> NS

    En el AUTHORITY SECTION resultado, anote el servidor de nombres que aparece a continuación. IN SOA Por ejemplo: ns-1458.awsdns-54.org.

  2. Consulta el servidor de nombres autorizado directamente para evitar las cachés:

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

    Esto devuelve las direcciones IP actuales del punto final, que reflejan la distribución real del tráfico basado en DNS.

  3. Utilice las direcciones IP resueltas para las conexiones de sus aplicaciones. Repita esta resolución periódicamente o cuando se produzcan errores de conexión para actualizar las direcciones.

Ejemplo:

# 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

Gestionar los cambios de IP de los nodos

importante

Las direcciones IP de los nodos no son estáticas. Cambian durante las conmutaciones por error, los reinicios de los nodos, las operaciones de mantenimiento y el escalado del clúster. Nunca almacene en caché las direcciones IP resueltas de forma indefinida.

Implemente estas prácticas para gestionar los cambios de IP:

  • Reresolución periódica: vuelva a resolver los puntos finales cada 30 a 60 segundos mediante una tarea en segundo plano. Compare las nuevas direcciones IP con los valores en caché y actualice el conjunto de conexiones en consecuencia.

  • Reresolución provocada por errores: cuando una conexión falla (se agota el tiempo de espera, se rechaza la conexión, se restablece), vuelve a resolver inmediatamente el punto final y vuelve a intentarlo con las direcciones IP actualizadas.

  • Se agota la conexión sin problemas: cuando una dirección IP ya no figura en el conjunto de registros de DNS, permite que se completen las solicitudes en curso, pero deja de crear nuevas conexiones a esa IP.

  • Creación de una nueva conexión: tras volver a resolverla, cree nuevas conexiones con las direcciones IP actualizadas. Las conexiones existentes fijadas a las antiguas no se IPs beneficiarán de la reresolución.

Prácticas recomendadas

  • Comience con la configuración TTL: en el caso de las aplicaciones Java, intente siempre realizar la configuración primero. networkaddress.cache.ttl=0 Esta es la solución más sencilla y eficaz.

  • Utilice la resolución directa con moderación: utilice únicamente consultas de servidores de nombres autoritativas cuando la configuración de TTL no sea suficiente o cuando se trate de un almacenamiento en caché intermedio persistente.

  • Automatice la detección de servidores de nombres: no codifique las direcciones de los servidores de nombres de forma rígida. Descúbrelas de forma dinámica, ya que las asignaciones de los servidores de nombres pueden cambiar.

  • Se aplica únicamente a los puntos finales del clúster: estas técnicas son para los puntos finales a nivel de clúster (escritura y lectura) que utilizan una distribución basada en DNS. Los puntos finales específicos de los nodos que se dirigen directamente a nodos individuales no requieren esta configuración.

  • Pruebe la implementación: compruebe que la aplicación distribuye correctamente las conexiones entre varios nodos y se recupera de los fallos de nodos simulados.