Verwaltung der DNS-Auflösung für Cluster-Endpunkte - Amazon Timestream
DNS-Caching verstehenLösung 1: Konfigurieren Sie JVM DNS TTL (Java-Anwendungen)Lösung 2: Direkte Lösung über autoritative NameserverBehandlung von Knoten-IP-ÄnderungenBest Practices

Für ähnliche Funktionen wie Amazon Timestream für sollten Sie Amazon Timestream for LiveAnalytics InfluxDB in Betracht ziehen. Es bietet eine vereinfachte Datenaufnahme und Antwortzeiten im einstelligen Millisekundenbereich für Analysen in Echtzeit. Erfahren Sie hier mehr.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwaltung der DNS-Auflösung für Cluster-Endpunkte

Timestream for InfluxDB für InfluxDB 3-Cluster mit mehreren Knoten verwendet eine DNS-basierte Verkehrsverteilung, um die Verbindungen zwischen den Knoten auszugleichen. Wenn ein Failover auftritt oder Knoten ersetzt werden, werden die DNS-Einträge automatisch aktualisiert, sodass sie auf verfügbare Instanzen verweisen. Um sicherzustellen, dass Ihre Anwendung diese Änderungen erkennen und eine optimale Verteilung des Datenverkehrs aufrechterhalten kann, ist eine korrekte Konfiguration der DNS-Auflösung unerlässlich.

DNS-Caching verstehen

In vielen Programmierumgebungen werden DNS-Lookups zwischengespeichert, um die Leistung zu verbessern. Diese Zwischenspeicherung kann jedoch verhindern, dass Ihre Anwendung nach einem Failover aktualisierte IP-Adressen erkennt oder Verbindungen auf mehrere Clusterknoten verteilt. Die Auswirkungen variieren je nach Sprache und Laufzeit:

  • Java/JVM-basierte Anwendungen — Die JVM speichert DNS-Lookups für eine konfigurierbare Datei (TTL) im Cache. time-to-live Manche Konfigurationen werden auf unbestimmte Zeit zwischengespeichert, bis die JVM neu gestartet wird.

  • Andere Sprachen — Python, Go, Node.js und andere Laufzeiten basieren in der Regel auf der DNS-Auflösung des Betriebssystems und weisen möglicherweise nicht dasselbe Caching-Verhalten auf.

Lösung 1: Konfigurieren Sie JVM DNS TTL (Java-Anwendungen)

Für Java-Anwendungen, die eine Verbindung zu Timestream for InfluxDB für InfluxDB 3-Cluster-Endpunkte herstellen, setzen Sie die JVM-DNS-Cache-TTL auf Null. Dadurch wird sichergestellt, dass jede Verbindung eine neue DNS-Suche auslöst, was eine korrekte Verteilung des Datenverkehrs und eine sofortige Failover-Erkennung ermöglicht.

Überprüfen Sie Ihre aktuelle TTL-Einstellung:

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

Konfigurieren Sie die TTL mit einer der folgenden Methoden:

  • Globale Konfiguration — Eingestellt networkaddress.cache.ttl in$JAVA_HOME/jre/lib/security/java.security:

    networkaddress.cache.ttl=0

  • Anwendungsspezifische Konfiguration — Legen Sie die Eigenschaft in Ihrem Anwendungsinitialisierungscode fest, bevor Sie Netzwerkverbindungen herstellen:

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

  • JVM-Argument — Als Systemeigenschaft übergeben, wenn Sie Ihre Anwendung starten:

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

Für Nicht-Cluster-Endpunkte oder allgemeine AWS Ressourcen ist eine TTL von 60 Sekunden in der Regel ausreichend. Die Null-TTL-Empfehlung ist spezifisch für InfluxDB 3-Cluster-Endpunkte, bei denen die Verkehrsverteilung und die schnelle Failover-Erkennung entscheidend sind.

Lösung 2: Direkte Lösung über autoritative Nameserver

Wenn die TTL-Konfiguration unzureichend ist, z. B. aufgrund eines Zwischenspeichers auf Betriebssystemebene oder wenn Ihre Programmiersprache keine Probleme mit dem DNS-Caching aufweist, können Sie eine neue DNS-Auflösung erzwingen, indem Sie autoritative Nameserver direkt abfragen. Verwenden Sie diesen Ansatz nur, wenn die Standard-TTL-Konfiguration das Problem nicht behebt.

Arbeitsablauf zur direkten Lösung

  1. Identifizieren Sie den autoritativen Nameserver für Ihren Cluster-Endpunkt:

    dig <cluster-endpoint> NS

    Notieren Sie sich in AUTHORITY SECTION der Ausgabe den Nameserver, der danach aufgeführt ist. IN SOA Beispiel: ns-1458.awsdns-54.org.

  2. Fragen Sie den autoritativen Nameserver direkt ab, um Caches zu umgehen:

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

    Dadurch werden die aktuellen IP-Adressen für den Endpunkt zurückgegeben, die die tatsächliche Verteilung des Datenverkehrs auf DNS-Basis widerspiegeln.

  3. Verwenden Sie die aufgelösten IP-Adressen für Ihre Anwendungsverbindungen. Wiederholen Sie diese Auflösung regelmäßig oder wenn Verbindungsfehler auftreten, um Adressen zu aktualisieren.

Beispiel:

# 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

Behandlung von Knoten-IP-Änderungen

Wichtig

Knoten-IP-Adressen sind nicht statisch. Sie ändern sich bei Failovers, Knotenneustarts, Wartungsvorgängen und Clusterskalierung. Zwischenspeichern Sie aufgelöste IP-Adressen niemals auf unbestimmte Zeit.

Implementieren Sie die folgenden Methoden, um IP-Änderungen zu handhaben:

  • Regelmäßige Neuauflösung — Endgeräte werden alle 30-60 Sekunden mithilfe einer Hintergrundaufgabe erneut aufgelöst. Vergleichen Sie neue IP-Adressen mit zwischengespeicherten Werten und aktualisieren Sie Ihren Verbindungspool entsprechend.

  • Fehlergesteuerte Neuauflösung — Wenn eine Verbindung fehlschlägt (Timeout, Verbindung verweigert, Reset), lösen Sie den Endpunkt sofort erneut auf und versuchen Sie es erneut mit aktualisierten IP-Adressen.

  • Automatischer Verbindungsabbau — Wenn eine IP-Adresse nicht mehr im DNS-Datensatz enthalten ist, lassen Sie zu, dass eingehende Anfragen abgeschlossen werden, aber stellen Sie keine neuen Verbindungen zu dieser IP her.

  • Erstellung neuer Verbindungen — Erstellen Sie nach der erneuten Auflösung neue Verbindungen mit aktualisierten IP-Adressen. Bestehende Verbindungen, die an alte Verbindungen geheftet sind, profitieren IPs nicht von einer erneuten Auflösung.

Best Practices

  • Beginnen Sie mit der TTL-Konfiguration — Versuchen Sie bei Java-Anwendungen immer zuerst, die Einstellung vorzunehmen. networkaddress.cache.ttl=0 Dies ist die einfachste und effektivste Lösung.

  • Direkte Auflösung sparsam verwenden — Verwenden Sie autorisierende Nameserver-Abfragen nur, wenn die TTL-Konfiguration unzureichend ist oder wenn es sich um persistentes Zwischen-Caching handelt.

  • Automatisieren Sie die Erkennung von Nameservern — Kodieren Sie Nameserveradressen nicht fest. Ermitteln Sie sie dynamisch, da sich die Nameserverzuweisungen ändern können.

  • Gilt nur für Cluster-Endpunkte — Diese Techniken sind für Endpunkte auf Clusterebene (Schreiben und Lesen) vorgesehen, die eine DNS-basierte Verteilung verwenden. Knotenspezifische Endpunkte, die direkt auf einzelne Knoten abzielen, benötigen diese Konfiguration nicht.

  • Testen Sie Ihre Implementierung — Stellen Sie sicher, dass Ihre Anwendung die Verbindungen korrekt auf mehrere Knoten verteilt und sich nach simulierten Knotenausfällen erholt.