Pemecahan masalah konektivitas

  • Artikel

Pada artikel ini, kami memberikan bantuan pemecahan masalah untuk menghubungkan aplikasi klien Anda ke Azure Cache for Redis. Masalah konektivitas dibagi menjadi dua jenis: masalah konektivitas terputus-putus dan masalah konektivitas berkelanjutan.

Masalah konektivitas yang terputus-terputus

Aplikasi klien Anda mungkin mengalami masalah konektivitas terputus-putus yang disebabkan oleh peristiwa seperti patching, atau lonjakan jumlah koneksi.

Pemeliharaan server

Terkadang, cache Anda mengalami pemeliharaan server yang direncanakan atau tidak direncanakan. Aplikasi Anda dapat terpengaruh secara negatif selama pemeliharaan. Anda dapat memvalidasi dengan memeriksa metrik Errors (Type: Failover) di portal Anda. Untuk meminimalkan efek failover, lihat Ketahanan koneksi.

Jumlah klien yang tersambungkan

Periksa apakah agregat Maks untuk metrik Connected Clients dekat atau lebih tinggi dari jumlah maksimum koneksi yang diizinkan untuk ukuran cache tertentu. Untuk informasi lebih lanjut tentang ukuran per sambungan klien, lihat Performa Azure Cache for Redis.

Aplikasi yang di-hosting Kubernetes

  • Jika aplikasi klien Anda di-hosting di Kubernetes, periksa apakah pod yang menjalankan aplikasi klien atau node kluster tidak berada di bawah tekanan memori/CPU/Jaringan. Pod yang menjalankan aplikasi klien dapat dipengaruhi oleh Pod lain yang berjalan pada node yang sama dan membatasi koneksi Redis atau operasi IO.
  • Jika Anda menggunakan Istio atau mesh layanan lainnya, periksa apakah proksi mesh layanan Anda mencadangkan port 13000-13019 atau 15000-15019. Port ini digunakan oleh klien untuk berkomunikasi dengan node Azure Cache For Redis berkluster dan dapat menyebabkan masalah konektivitas pada port tersebut.

Aplikasi klien berbasis Linux

Menggunakan pengaturan TCP optimis di Linux dapat menyebabkan aplikasi klien mengalami masalah konektivitas. Lihat Kegagalan koneksi yang berlangsung selama 15 menit.

Konektivitas berkelanjutan

Jika aplikasi Anda tidak dapat terhubung ke Azure Cache for Redis Anda, ada kemungkinan beberapa konfigurasi pada cache tidak disiapkan dengan benar. Bagian berikut menawarkan saran tentang cara memastikan cache Anda dikonfigurasi dengan benar.

Menguji konektivitas menggunakan redis-cli

Uji konektivitas menggunakan redis-cli. Untuk informasi selengkapnya tentang CLI, Gunakan alat baris perintah Redis dengan Azure Cache for Redis.

Menguji konektivitas menggunakan PSPING

Jika redis-cli tidak dapat terhubung, Anda dapat menguji konektivitas menggunakan PSPING di PowerShell.

psping -q <cache DNS endpoint>:<Port Number>

Anda dapat mengonfirmasi jumlah paket yang dikirim sama dengan paket yang diterima. Mengonfirmasi memastikan tidak ada penurunan konektivitas.

Konfigurasi jaringan virtual

Langkah-langkah untuk memeriksa konfigurasi jaringan virtual Anda:

  1. Periksa apakah jaringan virtual ditetapkan ke cache Anda dari bagian "Jaringan Virtual" di bagian Pengaturan pada menu Sumber Daya portal Azure.
  2. Pastikan komputer host klien berada di jaringan virtual yang sama dengan Azure Cache For Redis.
  3. Jika aplikasi klien berada di VNet yang berbeda dengan Azure Cache For Redis Anda, kedua VNet harus mengaktifkan peering VNet dalam wilayah Azure yang sama.
  4. Validasi bahwa aturan Masuk dan Keluar memenuhi persyaratan.
  5. Untuk informasi selengkapnya, lihat Mengonfigurasi jaringan virtual - instans Azure Cache for Redis tingkat Premium.

Konfigurasi titik akhir privat

Langkah-langkah untuk memeriksa konfigurasi titik akhir privat Anda:

  1. Bendera Public Network Access dinonaktifkan secara default saat membuat titik akhir privat. Pastikan Anda telah mengatur Public Network Access dengan benar. Saat Anda memiliki cache di portal Azure, lihat di bagian Titik Akhir Privat di menu Sumber Daya di sebelah kiri untuk pengaturan ini.
  2. Jika Anda mencoba menghubungkan ke titik akhir privat cache dari luar jaringan virtual cache, Public Network Access perlu diaktifkan.
  3. Jika Anda telah menghapus titik akhir privat, pastikan akses jaringan publik diaktifkan.
  4. Verifikasi apakah titik akhir privat Anda dikonfigurasi dengan benar. Untuk informasi selengkapnya, lihat Membuat titik akhir privat dengan instans Azure Cache for Redis baru.
  5. Verifikasi apakah aplikasi Anda tersambung ke <cachename>.redis.cache.windows.net pada port 6380. Sebaiknya hindari penggunaan <cachename>.privatelink.redis.cache.windows.net dalam konfigurasi atau string koneksi.
  6. Jalankan perintah seperti nslookup <hostname> dari dalam VNet yang ditautkan ke titik akhir privat untuk memverifikasi bahwa perintah diselesaikan ke alamat IP privat untuk cache.

Aturan firewall

Jika Anda mengonfigurasi firewall untuk Azure Cache For Redis, pastikan alamat IP klien Anda ditambahkan ke aturan firewall. Anda dapat memeriksa Firewall pada menu Sumber Daya di bagian Pengaturan di portal Azure.

Firewall pihak ketiga atau proksi eksternal

Saat menggunakan firewall atau proksi pihak ketiga di jaringan Anda, periksa apakah titik akhir untuk Azure Cache for Redis, *.redis.cache.windows.net, diizinkan beserta port 6379 dan 6380. Anda mungkin perlu mengizinkan lebih banyak port saat menggunakan cache atau geo-replikasi berkluster.

Perubahan alamat IP publik

Jika Anda telah mengonfigurasi sumber daya jaringan atau keamanan untuk menggunakan alamat IP publik cache Anda, periksa untuk melihat apakah alamat IP publik cache Anda berubah. Untuk informasi selengkapnya, lihat Mengandalkan nama host bukan alamat IP publik untuk cache Anda.

Replikasi geografis menggunakan injeksi VNet dengan cache Premium

Meskipun dimungkinkan untuk menggunakan injeksi VNet dengan cache Premium Anda, kami merekomendasikan Azure Private Link.

Untuk informasi selengkapnya, lihat:

Replikasi geografis cache di VNet didukung dengan peringatan:

  • Replikasi geografis antar-cache di VNet yang sama didukung.
  • Replikasi geografis antar-cache di VNet yang berbeda juga didukung.
    • Jika VNet berada di wilayah yang sama, Anda dapat menyambungkannya menggunakan peering VNet atau koneksi VPN Gateway VNet-ke-VNet.
    • Jika VNet berada di wilayah yang berbeda, replikasi geografis menggunakan peering VNet tidak didukung. VM klien di VNet 1(wilayah 1) tidak dapat mengakses cache di VNet 2 (wilayah 2) menggunakan nama DNS-nya karena batasan dengan penyeimbang beban internal Standar. Untuk informasi selengkapnya tentang batasan peering VNet, lihat Virtual Network - Peering - Persyaratan dan batasan. Sebaiknya gunakan koneksi VPN Gateway VNet ke VNet.

Untuk mengonfigurasikan VNet Anda secara efektif dan menghindari masalah replika geografis, Anda harus mengonfigurasi port masuk dan keluar dengan benar. Untuk informasi selengkapnya tentang menghindari masalah-masalah kesalahan konfigurasi VNet yang paling umum, lihat Persyaratan port serekan replikasi geografis.

Konten Terkait

Artikel ini memberikan informasi selengkapnya tentang konektivitas dan ketahanan: