Gerenciando a resolução de DNS para endpoints de cluster - Amazon Timestream
Entendendo o cache de DNSSolução 1: configurar o JVM DNS TTL (aplicativos Java)Solução 2: resolução direta por meio de servidores de nomes autorizadosTratamento de alterações de IP do nóPráticas recomendadas

Para recursos semelhantes aos do Amazon Timestream para, considere o Amazon Timestream LiveAnalytics para InfluxDB. Ele oferece ingestão de dados simplificada e tempos de resposta de consulta de um dígito em milissegundos para análises em tempo real. Saiba mais aqui.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Gerenciando a resolução de DNS para endpoints de cluster

Timestream for InfluxDB for InfluxDB 3 clusters de vários nós usam distribuição de tráfego baseada em DNS para equilibrar as conexões entre os nós. Quando ocorre um failover ou os nós são substituídos, os registros DNS são atualizados automaticamente para apontar para as instâncias disponíveis. Para garantir que seu aplicativo possa descobrir essas alterações e manter a distribuição ideal do tráfego, a configuração adequada da resolução de DNS é essencial.

Entendendo o cache de DNS

Muitos ambientes de programação armazenam em cache as pesquisas de DNS para melhorar o desempenho. No entanto, esse armazenamento em cache pode impedir que seu aplicativo descubra endereços IP atualizados após failovers ou distribua conexões em vários nós do cluster. O impacto varia de acordo com o idioma e o tempo de execução:

  • Aplicativos baseados em Java/JVM — A JVM armazena em cache as pesquisas de DNS para um configurável (TTL). time-to-live Algumas configurações armazenam em cache indefinidamente até que a JVM seja reiniciada.

  • Outras linguagens — Python, Go, Node.js e outros tempos de execução geralmente dependem da resolução de DNS do sistema operacional e podem não apresentar o mesmo comportamento de cache.

Solução 1: configurar o JVM DNS TTL (aplicativos Java)

Para aplicativos Java conectados ao Timestream for InfluxDB para endpoints de cluster InfluxDB 3, defina o TTL do cache DNS da JVM como zero. Isso garante que cada conexão acione uma nova pesquisa de DNS, permitindo a distribuição adequada do tráfego e a detecção imediata de failover.

Verifique sua configuração atual de TTL:

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

Configure o TTL usando um destes métodos:

  • Configuração global — Definida networkaddress.cache.ttl em$JAVA_HOME/jre/lib/security/java.security:

    networkaddress.cache.ttl=0

  • Configuração específica do aplicativo — Defina a propriedade no código de inicialização do aplicativo antes de estabelecer conexões de rede:

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

  • Argumento JVM — Passe como uma propriedade do sistema ao iniciar seu aplicativo:

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

Para endpoints que não são de cluster ou AWS recursos gerais, um TTL de 60 segundos geralmente é suficiente. A recomendação de zero TTL é específica para endpoints de cluster InfluxDB 3, onde a distribuição de tráfego e a detecção rápida de failover são essenciais.

Solução 2: resolução direta por meio de servidores de nomes autorizados

Se a configuração do TTL for insuficiente — por exemplo, devido ao cache intermediário no nível do sistema operacional ou se sua linguagem de programação não apresentar problemas de cache de DNS — você poderá forçar uma nova resolução de DNS consultando diretamente servidores de nomes autorizados. Use essa abordagem somente quando a configuração TTL padrão não resolver o problema.

Fluxo de trabalho de resolução direta

  1. Identifique o servidor de nomes autoritário para seu endpoint de cluster:

    dig <cluster-endpoint> NS

    Na saída, observe o servidor AUTHORITY SECTION de nomes listado a seguir. IN SOA Por exemplo: ns-1458.awsdns-54.org.

  2. Consulte o servidor de nomes autoritário diretamente para ignorar os caches:

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

    Isso retorna os endereços IP atuais do endpoint, refletindo a distribuição real do tráfego baseado em DNS.

  3. Use o (s) endereço (s) IP resolvido (s) para as conexões do seu aplicativo. Repita essa resolução periodicamente ou quando ocorrerem erros de conexão para atualizar endereços.

Exemplo:

# 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

Tratamento de alterações de IP do nó

Importante

Os endereços IP dos nós não são estáticos. Eles mudam durante failovers, reinicializações de nós, operações de manutenção e escalabilidade de clusters. Nunca armazene endereços IP resolvidos em cache indefinidamente.

Implemente essas práticas para lidar com mudanças de IP:

  • Resolução periódica — Resolva novamente os endpoints a cada 30 a 60 segundos usando uma tarefa em segundo plano. Compare novos endereços IP com valores em cache e atualize seu pool de conexões adequadamente.

  • Resolução baseada em erros — Quando uma conexão falhar (tempo limite, conexão recusada, redefinição), resolva imediatamente o endpoint e tente novamente com endereços IP atualizados.

  • Drenagem normal da conexão — Quando um endereço IP não estiver mais no conjunto de registros DNS, permita que as solicitações em andamento sejam concluídas, mas pare de criar novas conexões com esse IP.

  • Criação de nova conexão — Após a nova resolução, crie novas conexões usando endereços IP atualizados. As conexões existentes fixadas às antigas IPs não se beneficiarão da reresolução.

Práticas recomendadas

  • Comece com a configuração TTL — Para aplicativos Java, sempre tente configurar networkaddress.cache.ttl=0 primeiro. Essa é a solução mais simples e eficaz.

  • Use a resolução direta com moderação — Use somente consultas autoritativas de servidores de nomes quando a configuração TTL for insuficiente ou ao lidar com cache intermediário persistente.

  • Automatize a descoberta de servidores de nomes — não codifique endereços de servidores de nomes. Descubra-os dinamicamente, pois as atribuições do servidor de nomes podem mudar.

  • Aplica-se somente a endpoints de cluster — essas técnicas são para endpoints em nível de cluster (gravação e leitura) que usam distribuição baseada em DNS. Os endpoints específicos de nós que visam diretamente nós individuais não exigem essa configuração.

  • Teste sua implementação — verifique se seu aplicativo distribui corretamente as conexões em vários nós e se recupera de falhas simuladas de nós.