Gestione della risoluzione DNS per gli endpoint del cluster - Amazon Timestream
Comprendere la memorizzazione nella cache DNSSoluzione 1: configurare JVM DNS TTL (applicazioni Java)Soluzione 2: risoluzione diretta tramite nameserver autoritativiGestione delle modifiche IP dei nodiBest practice

Per funzionalità simili a Amazon Timestream for, prendi in considerazione Amazon Timestream LiveAnalytics per InfluxDB. Offre un'acquisizione semplificata dei dati e tempi di risposta alle query di una sola cifra di millisecondi per analisi in tempo reale. Scopri di più qui.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Gestione della risoluzione DNS per gli endpoint del cluster

I cluster multinodo Timestream for InfluxDB for InfluxDB 3 utilizzano la distribuzione del traffico basata su DNS per bilanciare le connessioni tra i nodi. Quando si verifica un failover o i nodi vengono sostituiti, i record DNS si aggiornano automaticamente in base alle istanze disponibili. Per garantire che l'applicazione possa rilevare queste modifiche e mantenere una distribuzione ottimale del traffico, è essenziale una corretta configurazione della risoluzione DNS.

Comprendere la memorizzazione nella cache DNS

Molti ambienti di programmazione memorizzano nella cache le ricerche DNS per migliorare le prestazioni. Tuttavia, questa memorizzazione nella cache può impedire all'applicazione di rilevare indirizzi IP aggiornati dopo i failover o di distribuire le connessioni tra più nodi del cluster. L'impatto varia in base alla lingua e al runtime:

  • Applicazioni basate su Java/JVM: la JVM memorizza nella cache le ricerche DNS per renderle configurabili (TTL). time-to-live Alcune configurazioni vengono memorizzate nella cache a tempo indeterminato fino al riavvio della JVM.

  • Altri linguaggi: Python, Go, Node.js e altri runtime in genere si basano sulla risoluzione DNS del sistema operativo e potrebbero non presentare lo stesso comportamento di memorizzazione nella cache.

Soluzione 1: configurare JVM DNS TTL (applicazioni Java)

Per le applicazioni Java che si connettono a Timestream for InfluxDB for InfluxDB per gli endpoint del cluster InfluxDB 3, imposta il TTL della cache DNS JVM su zero. Ciò garantisce che ogni connessione attivi una nuova ricerca DNS, consentendo una corretta distribuzione del traffico e il rilevamento immediato del failover.

Controlla la tua attuale impostazione TTL:

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

Configura il TTL utilizzando uno di questi metodi:

  • Configurazione globale: impostata networkaddress.cache.ttl in$JAVA_HOME/jre/lib/security/java.security:

    networkaddress.cache.ttl=0

  • Configurazione specifica dell'applicazione: imposta la proprietà nel codice di inizializzazione dell'applicazione prima di stabilire connessioni di rete:

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

  • Argomento JVM: passa come proprietà di sistema all'avvio dell'applicazione:

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

Per gli endpoint non cluster o le AWS risorse generali, in genere è sufficiente un TTL di 60 secondi. La raccomandazione zero TTL è specifica per gli endpoint del cluster InfluxDB 3 in cui la distribuzione del traffico e il rilevamento rapido del failover sono fondamentali.

Soluzione 2: risoluzione diretta tramite nameserver autoritativi

Se la configurazione TTL è insufficiente, ad esempio a causa della memorizzazione nella cache di livello intermedio del sistema operativo o se il linguaggio di programmazione non presenta problemi di memorizzazione nella cache DNS, puoi forzare una nuova risoluzione DNS interrogando direttamente i nameserver autoritativi. Utilizzate questo approccio solo quando la configurazione TTL standard non risolve il problema.

Flusso di lavoro con risoluzione diretta

  1. Identifica il nameserver autoritativo per l'endpoint del tuo cluster:

    dig <cluster-endpoint> NS

    Nell'output, annota AUTHORITY SECTION il nameserver elencato dopo. IN SOA Ad esempio: ns-1458.awsdns-54.org.

  2. Interroga direttamente il nameserver autorevole per bypassare le cache:

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

    Ciò restituisce gli indirizzi IP correnti per l'endpoint, che riflettono l'effettiva distribuzione del traffico basata su DNS.

  3. Utilizzate gli indirizzi IP risolti per le connessioni alle applicazioni. Ripeti questa risoluzione periodicamente o quando si verificano errori di connessione per aggiornare gli indirizzi.

Esempio:

# 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

Gestione delle modifiche IP dei nodi

Importante

Gli indirizzi IP dei nodi non sono statici. Cambiano durante i failover, i riavvii dei nodi, le operazioni di manutenzione e il ridimensionamento del cluster. Non memorizzare mai nella cache gli indirizzi IP risolti a tempo indeterminato.

Implementa queste pratiche per gestire le modifiche IP:

  • Risoluzione periodica: risolvi nuovamente gli endpoint ogni 30-60 secondi utilizzando un'attività in background. Confronta i nuovi indirizzi IP con i valori memorizzati nella cache e aggiorna di conseguenza il tuo pool di connessioni.

  • Risoluzione basata su errori: quando una connessione fallisce (timeout, connessione rifiutata, reset), risolvi immediatamente l'endpoint e riprova con gli indirizzi IP aggiornati.

  • Efficiente esaurimento della connessione: quando un indirizzo IP non è più presente nel set di record DNS, consenti il completamento delle richieste in corso ma interrompi la creazione di nuove connessioni a quell'IP.

  • Creazione di una nuova connessione: dopo la nuova risoluzione, crea nuove connessioni utilizzando indirizzi IP aggiornati. Le connessioni esistenti collegate a quelle precedenti IPs non trarranno vantaggio dalla nuova risoluzione.

Best practice

  • Inizia con la configurazione TTL: per le applicazioni Java, prova sempre prima a impostare. networkaddress.cache.ttl=0 Questa è la soluzione più semplice ed efficace.

  • Usa la risoluzione diretta con parsimonia: utilizza query autorevoli sui nameserver solo quando la configurazione TTL è insufficiente o quando si ha a che fare con un caching intermedio persistente.

  • Automatizza l'individuazione dei nameserver: non codificate gli indirizzi dei nameserver. Scoprili dinamicamente poiché le assegnazioni dei nameserver possono cambiare.

  • Si applica solo agli endpoint del cluster: queste tecniche sono destinate agli endpoint a livello di cluster (scrittura e lettura) che utilizzano la distribuzione basata su DNS. Gli endpoint specifici dei nodi che si rivolgono direttamente ai singoli nodi non richiedono questa configurazione.

  • Testa la tua implementazione: verifica che l'applicazione distribuisca correttamente le connessioni su più nodi e ripristini il sistema in caso di guasti simulati dei nodi.