View a markdown version of this page

Mengelola resolusi DNS untuk titik akhir klaster - Amazon Timestream
Memahami caching DNSSolusi 1: Konfigurasikan JVM DNS TTL (aplikasi Java)Solusi 2: Resolusi langsung melalui server nama otoritatifMenangani perubahan IP nodePraktik terbaik

Untuk kemampuan serupa dengan Amazon Timestream LiveAnalytics, pertimbangkan Amazon Timestream untuk InfluxDB. Ini menawarkan konsumsi data yang disederhanakan dan waktu respons kueri milidetik satu digit untuk analitik waktu nyata. Pelajari lebih lanjut di sini.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mengelola resolusi DNS untuk titik akhir klaster

Timestream untuk InfluxDB untuk cluster multi-node InfluxDB 3 menggunakan distribusi lalu lintas berbasis DNS untuk menyeimbangkan koneksi di seluruh node. Ketika failover terjadi atau node diganti, catatan DNS secara otomatis diperbarui untuk menunjuk ke instance yang tersedia. Untuk memastikan aplikasi Anda dapat menemukan perubahan ini dan mempertahankan distribusi lalu lintas yang optimal, konfigurasi resolusi DNS yang tepat sangat penting.

Memahami caching DNS

Banyak lingkungan pemrograman cache pencarian DNS untuk meningkatkan kinerja. Namun, caching ini dapat mencegah aplikasi Anda menemukan alamat IP yang diperbarui setelah kegagalan atau mendistribusikan koneksi di beberapa node cluster. Dampaknya bervariasi menurut bahasa dan runtime:

  • Aplikasi berbasis Java/JVM - JVM menyimpan pencarian DNS untuk dikonfigurasi (TTL). time-to-live Beberapa konfigurasi cache tanpa batas hingga JVM restart.

  • Bahasa lain — Python, Go, Node.js, dan runtime lainnya biasanya bergantung pada resolusi DNS sistem operasi dan mungkin tidak menunjukkan perilaku caching yang sama.

Solusi 1: Konfigurasikan JVM DNS TTL (aplikasi Java)

Untuk aplikasi Java yang terhubung ke Timestream untuk InfluxDB untuk titik akhir cluster InfluxDB 3, atur TTL cache DNS JVM ke nol. Ini memastikan setiap koneksi memicu pencarian DNS baru, memungkinkan distribusi lalu lintas yang tepat dan deteksi failover segera.

Periksa pengaturan TTL Anda saat ini:

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

Konfigurasikan TTL menggunakan salah satu metode ini:

  • Konfigurasi global - Atur networkaddress.cache.ttl di$JAVA_HOME/jre/lib/security/java.security:

    networkaddress.cache.ttl=0

  • Konfigurasi khusus aplikasi - Mengatur properti dalam kode inisialisasi aplikasi Anda sebelum membuat koneksi jaringan:

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

  • Argumen JVM - Lulus sebagai properti sistem saat memulai aplikasi Anda:

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

Untuk endpoint non-cluster atau AWS sumber daya umum, TTL 60 detik biasanya cukup. Rekomendasi nol TTL khusus untuk titik akhir cluster InfluxDB 3 di mana distribusi lalu lintas dan deteksi failover cepat sangat penting.

Solusi 2: Resolusi langsung melalui server nama otoritatif

Jika konfigurasi TTL tidak mencukupi - misalnya, karena caching tingkat OS menengah, atau jika bahasa pemrograman Anda tidak menunjukkan masalah caching DNS - Anda dapat memaksa resolusi DNS baru dengan menanyakan server nama otoritatif secara langsung. Gunakan pendekatan ini hanya jika konfigurasi TTL standar tidak menyelesaikan masalah.

Alur kerja resolusi langsung

  1. Identifikasi nameserver otoritatif untuk titik akhir klaster Anda:

    dig <cluster-endpoint> NS

    Di AUTHORITY SECTION output, perhatikan nameserver yang tercantum setelahnya. IN SOA Sebagai contoh: ns-1458.awsdns-54.org.

  2. Kueri nameserver otoritatif secara langsung untuk mem-bypass cache:

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

    Ini mengembalikan alamat IP saat ini untuk titik akhir, yang mencerminkan distribusi lalu lintas berbasis DNS yang sebenarnya.

  3. Gunakan alamat IP yang diselesaikan untuk koneksi aplikasi Anda. Ulangi resolusi ini secara berkala atau ketika kesalahan koneksi terjadi untuk menyegarkan alamat.

Contoh:

# 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

Menangani perubahan IP node

penting

Alamat IP node tidak statis. Mereka berubah selama failover, restart node, operasi pemeliharaan, dan penskalaan cluster. Jangan pernah cache diselesaikan alamat IP tanpa batas waktu.

Terapkan praktik ini untuk menangani perubahan IP:

  • Resolusi ulang berkala - Selesaikan ulang titik akhir setiap 30-60 detik menggunakan tugas latar belakang. Bandingkan alamat IP baru dengan nilai cache dan perbarui kumpulan koneksi Anda.

  • Resolusi ulang yang digerakkan oleh kesalahan — Ketika koneksi gagal (batas waktu, koneksi ditolak, reset), segera selesaikan kembali titik akhir dan coba lagi dengan alamat IP yang diperbarui.

  • Pengurasan koneksi yang anggun — Ketika alamat IP tidak lagi ada dalam kumpulan catatan DNS, izinkan permintaan dalam penerbangan selesai tetapi berhenti membuat koneksi baru ke IP itu.

  • Pembuatan koneksi baru — Setelah resolusi ulang, buat koneksi baru menggunakan alamat IP yang diperbarui. Koneksi yang ada yang disematkan ke lama tidak IPs akan mendapat manfaat dari resolusi ulang.

Praktik terbaik

  • Mulai dengan konfigurasi TTL - Untuk aplikasi Java, selalu coba pengaturan networkaddress.cache.ttl=0 terlebih dahulu. Ini adalah solusi paling sederhana dan paling efektif.

  • Gunakan resolusi langsung dengan hemat — Hanya gunakan kueri server nama otoritatif ketika konfigurasi TTL tidak mencukupi atau saat berhadapan dengan cache perantara persisten.

  • Otomatiskan penemuan nameserver — Jangan hardcode alamat nameserver. Temukan mereka secara dinamis karena tugas nameserver dapat berubah.

  • Hanya berlaku untuk titik akhir cluster — Teknik ini untuk titik akhir tingkat cluster (tulis dan baca) yang menggunakan distribusi berbasis DNS. Titik akhir khusus node yang menargetkan node individu secara langsung tidak memerlukan konfigurasi ini.

  • Uji implementasi Anda — Verifikasi bahwa aplikasi Anda mendistribusikan koneksi dengan benar di beberapa node dan pulih dari kegagalan simpul yang disimulasikan.