Bagikan melalui

Mengonfigurasi dukungan jaringan virtual (VNet) untuk instans Premium Azure Cache for Redis

  • Artikel

Penerapan Azure Virtual Network menyediakan keamanan dan isolasi yang ditingkatkan bersama dengan: subnet, kebijakan kontrol akses, dan fitur lainnya untuk membatasi akses lebih lanjut. Saat instans Azure Cache for Redis dikonfigurasi dengan jaringan virtual, instans tersebut tidak dapat diatasi secara publik. Sebaliknya, instans hanya dapat diakses dari komputer virtual dan aplikasi dalam jaringan virtual. Artikel ini menjelaskan cara mengonfigurasi dukungan jaringan virtual untuk intans Azure Cache for Redis tingkat Premium.

Catatan

Model penyebaran klasik dihentikan pada Agustus 2024. Untuk informasi selengkapnya, lihat Model penyebaran Cloud Services (klasik) akan dihentikan pada 31 Agustus 2024.

Penting

Azure Cache for Redis merekomendasikan penggunaan Azure Private Link, yang menyederhanakan arsitektur jaringan dan mengamankan koneksi antar titik akhir di Azure. Anda dapat menyambungkan ke instans Azure Cache dari jaringan virtual Anda melalui titik akhir privat, yang diberi alamat IP pribadi dalam subnet dalam jaringan virtual. Azure Private Links ditawarkan di semua tingkatan kami, termasuk dukungan Azure Policy, dan manajemen aturan NSG yang disederhanakan. Untuk mempelajari selengkapnya, lihat Dokumentasi Azure Private Link. Untuk memigrasikan cache yang disuntikkan VNet ke Private Link, lihat Memigrasikan dari cache suntikan VNet ke cache Private Link.

Keterbatasan injeksi VNet

  • Membuat dan memelihara konfigurasi jaringan virtual seringkali rawan kesalahan. Pemecahan masalah juga menantang. Konfigurasi jaringan virtual yang salah dapat menyebabkan masalah:
    • transmisi metrik terhalang dari instans cache Anda
    • kegagalan simpul replika untuk mereplikasi data dari simpul utama
    • potensi kehilangan data
    • kegagalan operasi manajemen seperti penskalaan
    • dalam skenario yang paling parah, hilangnya ketersediaan
  • Cache yang disuntikkan VNet hanya tersedia untuk Azure Cache for Redis tingkat Premium, bukan tingkatan lain.
  • Saat menggunakan cache yang disuntikkan VNet, Anda harus mengubah VNet menjadi dependensi cache seperti CRL/PKI, AKV, Azure Storage, Azure Monitor, dan lainnya.
  • Anda tidak dapat menyuntikkan instans Azure Cache for Redis yang ada ke dalam Virtual Network. Anda harus memilih opsi ini saat membuat cache.

Menyetel dukungan jaringan virtual

Dukungan jaringan virtual dikonfigurasi pada panel Azure Cache for Redis Baru selama pembuatan cache.

  1. Untuk membuat cache tingkat Premium, masuk ke portal Microsoft Azure dan pilih Buat sumber daya. Anda juga dapat membuatnya dengan menggunakan templat Resource Manager, PowerShell, atau Azure CLI. Untuk informasi selengkapnya tentang cara membuat instans Azure Cache for Redis, lihat Membuat cache.

    Cuplikan layar yang memperlihatkan Buat sumber daya.

  2. Pada halaman Baru, pilih Database. Lalu pilih Azure Cache for Redis.

    Cuplikan layar yang memperlihatkan memilih Azure Cache for Redis.

  3. Pada halaman Redis Cache Baru, konfigurasikan pengaturan untuk cache tingkat Premium baru Anda.

    Pengaturan Nilai yang disarankan Deskripsi
    Nama DNS Masukkan nama yang unik secara global. Nama cache harus merupakan untai (karakter) antara 1 dan 63 karakter yang hanya berisi angka, huruf, atau tanda hubung. Nama harus dimulai dan diakhiri dengan angka atau huruf, dan tidak boleh berisi tanda hubung berturut-turut. Nama host instans cache Anda adalah \<DNS name>.redis.cache.windows.net.
    Langganan Pilih langganan Anda dari daftar drop-down. Langganan untuk membuat instans Azure Cache for Redis baru ini.
    Grup sumber daya Pilih grup sumber daya dari daftar drop-down, atau pilih Buat baru dan masukkan nama grup sumber daya baru. Nama untuk grup sumber daya tempat membuat cache dan sumber daya lainnya. Dengan menyatukan semua sumber daya aplikasi dalam satu grup sumber daya, Anda dapat dengan mudah mengelola atau menghapusnya sekaligus.
    Location Pilih lokasi dari daftar drop-down. Pilih wilayah di dekat layanan lain yang akan menggunakan cache Anda.
    Jenis cache Pilih cache tingkat Premium dari daftar drop-down untuk mengonfigurasi fitur tingkat Premium. Untuk informasi selengkapnya, lihat Harga Azure Cache for Redis. Tingkat harga menentukan ukuran, performa, dan fitur yang tersedia untuk cache tersebut. Untuk informasi selengkapnya, lihat Gambaran Umum Azure Cache for Redis.

  4. Pilih tab Jaringan atau pilih tombol Jaringan di bagian bawah halaman.

  5. Pada tab Jaringan, pilih Jaringan Virtual sebagai metode konektivitas Anda. Untuk menggunakan jaringan virtual baru, buatlah terlebih dahulu dengan mengikuti langkah-langkah dalam Membuat jaringan virtual menggunakan portal Microsoft Azure atau Membuat jaringan virtual (klasik) dengan menggunakan portal Microsoft Azure. Lalu kembali ke panel Azure Cache for Redis Baru untuk membuat dan mengonfigurasi cache tingkat Premium Anda.

    Penting

    Saat Anda menggunakan Azure Cache for Redis ke jaringan virtual Resource Manager, cache harus berada di subnet khusus yang tidak berisi sumber daya lain kecuali untuk instans Azure Cache for Redis. Jika Anda mencoba menerapkan instans Azure Cache for Redis ke subnet jaringan virtual Resource Manager yang berisi sumber daya lain, atau memiliki NAT Gateway yang ditetapkan, penyebaran gagal. Kegagalannya karena Azure Cache for Redis menggunakan penyeimbang muatan dasar yang tidak kompatibel dengan NAT Gateway.

    Pengaturan Nilai yang disarankan Deskripsi
    Jaringan virtual Pilih jaringan virtual Anda dari daftar drop-down. Pilih jaringan virtual yang berada di langganan dan lokasi yang sama dengan cache Anda.
    Subnet Pilih subnet Anda dari daftar drop-down. Rentang alamat subnet harus dalam notasi CIDR (misalnya, 192.168.1.0/24). Ini harus dikandung oleh ruang alamat jaringan virtual.
    Alamat IP statis (Opsional) Masukkan alamat IP statik. Jika Anda tidak menentukan alamat IP statik, alamat IP dipilih secara otomatis.

    Penting

    Azure mempertahankan beberapa alamat IP dalam setiap subnet, dan alamat ini tidak dapat digunakan. Alamat IP pertama dan terakhir dari subnet dicadangkan untuk kesesuaian protokol, bersama dengan tiga alamat lain yang digunakan untuk layanan Azure. Untuk informasi lebih lanjut, lihat Apakah ada batasan saat menggunakan alamat IP dalam subnet ini?

    Selain alamat IP yang digunakan oleh infrastruktur jaringan virtual Azure, setiap instans Azure Cache for Redis di subnet menggunakan dua alamat IP per shard dan satu alamat IP tambahan untuk load balancer. Cache yang tidak termasuk dianggap memiliki satu shard.

  6. Pilih tab Berikutnya: Tingkat Lanjut, atau pilih tombol Berikutnya: Tingkat Lanjut di bagian bawah halaman.

  7. Pada tab Tingkat Lanjut untuk instans cache tingkat Premium, konfigurasikan pengaturan untuk port non-TLS, pengelompokan, dan persistensi data.

  8. Pilih tab Berikutnya: Tag atau pilih tombol Berikutnya: Tag di bagian bawah halaman.

  9. Secara opsional, pada tab Tag, masukkan nama dan nilai jika Anda ingin mengkategorikan sumber daya.

  10. Pilih Tinjau + buat. Anda dibawa ke tab Tinjau + buat tempat Azure memvalidasi konfigurasi Anda.

  11. Setelah pesan hijauLulus validasi muncul, pilih Buat.

Perlu waktu beberapa saat agar cache dibuat. Anda dapat memantau kemajuan di halaman Gambaran Umum Azure Cache for Redis. Ketika Status muncul sebagai Sedang Berjalan, cache siap digunakan. Setelah cache dibuat, Anda dapat melihat konfigurasi untuk jaringan virtual dengan memilih Jaringan Virtual dari menu Sumber Daya.

Jaringan virtual

Tanya Jawab Umum jaringan virtual Azure Cache for Redis

Daftar berikut berisi jawaban atas pertanyaan umum tentang jaringan Azure Cache for Redis.

Apa saja masalah konfigurasi umum dengan Azure Cache for Redis dan jaringan virtual?

Saat Azure Cache for Redis dihosting di jaringan virtual, port dalam tabel berikut ini digunakan.

Penting

Jika port dalam tabel berikut diblokir, cache mungkin tidak berfungsi dengan benar. Memiliki satu atau beberapa port ini diblokir adalah masalah kesalahan konfigurasi yang paling umum ketika Anda menggunakan Azure Cache for Redis dalam jaringan virtual.

Persyaratan port keluar

Ada sembilan persyaratan port keluar. Permintaan keluar dalam rentang ini adalah: a) keluar ke layanan lain yang diperlukan agar cache berfungsi, atau b) internal ke subnet Redis untuk komunikasi internode. Untuk replikasi geografis, persyaratan keluar lainnya ada untuk komunikasi antara subnet dari cache primer dan replika.

Port Petunjuk Protokol transportasi Tujuan IP Lokal IP Jarak Jauh
80, 443 Keluar TCP Redis dependensi pada Microsoft Azure Storage/PKI (internet) (Redis subnet) * 4
443 Keluar TCP Mengulangi dependensi pada Azure Key Vault dan Azure Monitor (Redis subnet) AzureKeyVault, AzureMonitor 1
53 Keluar TCP/UDP Aktifkan kembali dependensi pada DNS (jaringan internet/virtual) (Redis subnet) 168.63.129.16 and 169.254.169.254 2 dan server DNS kustom untuk subnet 3
8443 Keluar TCP Komunikasi internal untuk Redis (Redis subnet) (Redis subnet)
10221-10231 Keluar TCP Komunikasi internal untuk Redis (Redis subnet) (Redis subnet)
20226 Keluar TCP Komunikasi internal untuk Redis (Redis subnet) (Redis subnet)
13000-13999 Keluar TCP Komunikasi internal untuk Redis (Redis subnet) (Redis subnet)
15000-15999 Keluar TCP Komunikasi internal untuk Redis dan geo-replikasi (Redis subnet) (Redis subnet) (Geo-replica peer subnet)
6379-6380 Keluar TCP Komunikasi internal untuk Redis (Redis subnet) (Redis subnet)

1 Anda dapat menggunakan tag layanan AzureKeyVault dan AzureMonitor dengan grup keamanan jaringan Resource Manager (NSG).

2 Alamat IP yang dimiliki oleh Microsoft ini digunakan untuk mengatasi VM host yang melayani Azure DNS.

3 Informasi ini tidak diperlukan untuk subnet tanpa server DNS kustom atau cache Redis yang lebih baru yang mengabaikan DNS kustom.

4 Untuk informasi selengkapnya, lihat Persyaratan konektivitas jaringan virtual tambahan.

Persyaratan port peer geo-replikasi

Jika Anda menggunakan replikasi geografis antara cache di jaringan virtual Azure: a) buka blokir port 15000-15999 untuk seluruh subnet dalam arah masuk dan keluar, dan b) ke kedua cache. Dengan konfigurasi ini, semua komponen replika di subnet dapat berkomunikasi langsung satu sama lain bahkan jika ada kegagalan geografis di masa depan.

Persyaratan port masuk

Ada delapan persyaratan jangkauan port masuk. Permintaan masuk dalam rentang ini masuk dari layanan lain yang dihosting dalam jaringan virtual yang sama. Atau, mereka adalah internal untuk Redis subnet komunikasi.

Port Petunjuk Protokol transportasi Tujuan IP Lokal IP Jarak Jauh
6379, 6380 Masuk TCP Komunikasi klien ke Redis, penyeimbangan beban Azure (Redis subnet) (Redis subnet), (Client subnet), AzureLoadBalancer 1
8443 Masuk TCP Komunikasi internal untuk Redis (Redis subnet) (Redis subnet)
8500 Masuk TCP/UDP Penyeimbangan muatan Azure (Redis subnet) AzureLoadBalancer
10221-10231 Masuk TCP Komunikasi klien ke Klaster Redis, komunikasi internal untuk Redis (Redis subnet) (Redis subnet), (Client subnet), AzureLoadBalancer
13000-13999 Masuk TCP Komunikasi klien ke Klaster Redis, penyeimbangan beban Azure (Redis subnet) (Redis subnet), (Client subnet), AzureLoadBalancer
15000-15999 Masuk TCP Komunikasi klien ke Klaster Redis, penyeimbangan beban Azure, dan replikasi geografis (Redis subnet) (Redis subnet), (Client subnet), AzureLoadBalancer, (Geo-replica peer subnet)
16001 Masuk TCP/UDP Penyeimbangan muatan Azure (Redis subnet) AzureLoadBalancer
20226 Masuk TCP Komunikasi internal untuk Redis (Redis subnet) (Redis subnet)

1 Anda dapat menggunakan tag layanan AzureLoadBalancer untuk Resource Manager atau AZURE_LOADBALANCER untuk model penerapan klasik untuk menulis aturan NSG.

Persyaratan konektivitas jaringan virtual tambahan

Ada persyaratan konektivitas jaringan untuk Azure Cache for Redis yang awalnya tidak terpenuhi dalam jaringan virtual. Azure Cache for Redis mengharuskan semua item berikut berfungsi dengan baik saat digunakan dalam jaringan virtual:

  • Konektivitas jaringan keluar ke titik akhir Azure Key Vault di seluruh dunia. Titik akhir Azure Key Vault diselesaikan di bawah domain vault.azure.netDNS .
  • Konektivitas jaringan keluar ke titik akhir Microsoft Azure Storage di seluruh dunia. Titik akhir yang terletak di wilayah yang sama dengan instans Azure Cache for Redis dan titik akhir penyimpanan yang terletak di wilayah Azure lainnya disertakan. Titik akhir Azure Storage diselesaikan di bawah domain DNS berikut: table.core.windows.net, , blob.core.windows.netqueue.core.windows.net, dan file.core.windows.net.
  • Konektivitas jaringan keluar ke ocsp.digicert.com, , crl4.digicert.com, ocsp.msocsp.commscrl.microsoft.com, crl3.digicert.com, cacerts.digicert.com, oneocsp.microsoft.comdan crl.microsoft.com. Konektivitas ini diperlukan untuk mendukung fungsionalitas TLS/SSL.
  • Konfigurasi DNS untuk jaringan virtual harus dapat menyelesaikan semua titik akhir dan domain yang disebutkan di titik-titik sebelumnya. Persyaratan DNS ini dapat dipenuhi dengan memastikan infrastruktur DNS yang valid dikonfigurasi dan dikelola untuk jaringan virtual.
  • Konektivitas jaringan keluar ke titik akhir Azure Monitor berikut, yang diselesaikan di bawah domain DNS berikut: shoebox2-black.shoebox2.metrics.nsatc.net, , , north-prod2.prod2.metrics.nsatc.netazglobal-black.azglobal.metrics.nsatc.net, shoebox2-red.shoebox2.metrics.nsatc.net, azglobal-red.azglobal.metrics.nsatc.neteast-prod2.prod2.metrics.nsatc.net, shoebox3.prod.microsoftmetrics.com, shoebox3-red.prod.microsoftmetrics.com, , shoebox3-black.prod.microsoftmetrics.com, dan azredis-red.prod.microsoftmetrics.com azredis-black.prod.microsoftmetrics.com.

Bagaimana cara memverifikasi bahwa cache saya berfungsi di jaringan virtual?

Penting

Saat Anda menyambungkan ke instans Azure Cache for Redis yang dihosting di jaringan virtual, klien cache Anda harus berada di jaringan virtual yang sama atau di jaringan virtual dengan peering jaringan virtual yang diaktifkan dalam wilayah Azure yang sama. Peering jaringan virtual global saat ini tidak didukung. Persyaratan ini berlaku untuk aplikasi pengujian atau alat ping diagnostik apa pun. Terlepas dari di mana aplikasi klien dihosting, NSG atau lapisan jaringan lainnya harus dikonfigurasi sedemikian rupa sehingga lalu lintas jaringan klien diizinkan untuk mencapai instans Azure Cache for Redis.

Setelah persyaratan port dikonfigurasi seperti yang dijelaskan di bagian sebelumnya, reboot diperlukan dalam banyak kasus untuk memastikan perubahan tercermin dengan benar. Jika tidak, Anda mungkin mengalami beberapa masalah konektivitas. Anda dapat memverifikasi bahwa cache Anda berfungsi dengan mengikuti langkah-langkah berikut:

  • Reboot semua node cache. Cache tidak akan berhasil dimulai ulang jika semua dependensi cache yang diperlukan tidak dapat dijangkau---semua yang didokumentasikan dalam persyaratan port masuk dan persyaratan port keluar.
  • Setelah simpul cache dimulai ulang, seperti yang dilaporkan oleh status cache di portal Azure, Anda dapat melakukan pengujian berikut:

    • Ping titik akhir cache dengan menggunakan port 6380 dari komputer yang berada dalam jaringan virtual yang sama dengan cache, menggunakan tcping. Contohnya:

      tcping.exe contosocache.redis.cache.windows.net 6380

      Jika tcping alat melaporkan bahwa port terbuka, cache tersedia untuk koneksi dari klien di jaringan virtual.

    • Cara lain untuk menguji: buat klien cache pengujian yang terhubung ke cache, lalu tambahkan dan ambil beberapa item dari cache. Klien cache pengujian bisa menjadi aplikasi konsol menggunakan StackExchange.Redis. Instal contoh aplikasi klien ke VM yang berada di jaringan virtual yang sama dengan cache. Kemudian, jalankan untuk memverifikasi konektivitas ke cache.

Ketika saya mencoba menyambungkan ke instans Azure Cache for Redis saya di jaringan virtual, mengapa saya mendapatkan kesalahan yang menyatakan sertifikat jarak jauh tidak valid?

Saat Anda mencoba menyambungkan ke contoh Azure Cache for Redis di jaringan virtual, Anda akan melihat kesalahan validasi sertifikat seperti ini:

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

Penyebabnya bisa jadi Anda terhubung ke host berdasarkan alamat IP. Kami menyarankan agar Anda menggunakan nama host. Dengan kata lain, gunakan string berikut:

[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Hindari menggunakan alamat IP yang mirip dengan string koneksi berikut:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Jika Anda tidak dapat mengatasi nama DNS, beberapa pustaka klien menyertakan opsi konfigurasi seperti sslHost, yang disediakan oleh klien StackExchange.Redis. Opsi ini memungkinkan Anda untuk mengganti nama host yang digunakan untuk validasi sertifikat. Contohnya:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net

Dapatkah saya menggunakan jaringan virtual dengan cache standar atau dasar?

Jaringan virtual hanya dapat digunakan dengan cache tingkat Premium.

Mengapa membuat instans Azure Cache for Redis gagal di beberapa subnet tetapi tidak yang lain?

Jika Anda menggunakan instans Azure Cache for Redis ke jaringan virtual, cache harus berada dalam subnet khusus yang tidak berisi jenis sumber daya lain. Jika upaya dilakukan untuk menerapkan instans Azure Cache for Redis ke subnet jaringan virtual Resource Manager yang berisi sumber daya lain---seperti instans Azure Application Gateway dan Outbound NAT--- penyebaran biasanya gagal. Hapus sumber daya yang sudah ada dari tipe lain sebelum Anda membuat instans Azure Cache for Redis.

Anda juga harus memiliki cukup alamat IP yang tersedia di subnet.

Apa persyaratan ruang alamat subnet?

Azure mempertahankan beberapa alamat IP dalam setiap subnet, dan alamat ini tidak dapat digunakan. Alamat IP pertama dan terakhir dari subnet dicadangkan untuk kesesuaian protokol, bersama dengan tiga alamat lain yang digunakan untuk layanan Azure. Untuk informasi lebih lanjut, lihat Apakah ada batasan saat menggunakan alamat IP dalam subnet ini?

Selain alamat IP yang digunakan oleh infrastruktur jaringan virtual Azure, setiap instans Azure Cache for Redis di subnet menggunakan dua alamat IP per shard kluster, ditambah alamat IP untuk replika tambahan, jika ada. Satu lagi alamat IP digunakan untuk load balancer. Cache yang tidak terklaster dianggap memiliki satu shard.

Bisakah saya menyambungkan ke cache saya dari jaringan virtual yang di-peered?

Jika jaringan virtual berada di wilayah yang sama, Anda dapat menghubungkannya menggunakan peering jaringan virtual atau koneksi VPN Gateway VNET-to-VNET.

Jika jaringan virtual Azure yang dilakukan peer berada di wilayah yang berbeda: VM klien di wilayah 1 tidak dapat mengakses cache di wilayah 2 melalui alamat IP seimbang bebannya karena batasan dengan load balancer. Artinya, kecuali itu adalah cache dengan load balancers standar, yang saat ini hanya cache yang dibuat dengan zona ketersediaan.

Untuk informasi selengkapnya tentang batasan peering jaringan virtual, lihat Jaringan Virtual - Peering - Persyaratan dan batasan. Salah satu solusinya adalah dengan menggunakan koneksi VPN Gateway VNET-to-VNET alih-alih peering jaringan virtual.

Apakah semua fitur cache berfungsi saat cache dihosting di jaringan virtual?

Ketika cache Anda adalah bagian dari jaringan virtual, hanya klien di jaringan virtual yang dapat mengakses cache. Akibatnya, fitur manajemen cache berikut tidak berfungsi saat ini:

  • Konsol Redis:Karena Konsol Redis berjalan di browser lokal Anda---biasanyat menggunakan komputer pengembang yang tidak terhubung ke jaringan virtual---yang tidak dapat terhubung ke cache Anda.

Apakah injeksi VNet didukung pada cache tempat Azure Lighthouse diaktifkan?

Tidak, jika langganan Anda mengaktifkan Azure Lighthouse, Anda tidak dapat menggunakan injeksi VNet pada instans Azure Cache for Redis. Sebagai gantinya, gunakan tautan privat.

Menggunakan ExpressRoute dengan Azure Cache for Redis

Pelanggan dapat menghubungkan sirkuit Azure ExpressRoute ke infrastruktur jaringan virtual mereka. Dengan cara ini, mereka memperluas jaringan lokal mereka ke Azure.

Secara default, sirkuit ExpressRoute yang baru dibuat tidak melakukan penerowongan paksa (iklan rute default, 0.0.0.0/0) di jaringan virtual. Akibatnya, konektivitas internet keluar diizinkan langsung dari jaringan virtual. Aplikasi klien dapat terhubung ke titik akhir Azure lainnya, yang menyertakan instans Azure Cache for Redis.

Konfigurasi pelanggan umum adalah menggunakan penerowongan paksa (mengiklankan rute default), yang memaksa lalu lintas internet keluar untuk sebaliknya mengalir di tempat. Arus lalu lintas ini memutus konektivitas dengan Azure Cache for Redis jika lalu lintas keluar kemudian diblokir di tempat sedemikian rupa sehingga instans Azure Cache for Redis tidak dapat berkomunikasi dengan dependensinya.

Solusinya adalah menentukan satu atau beberapa rute yang ditentukan pengguna (UDR) pada subnet yang berisi instans Azure Cache for Redis. UDR mendefinisikan rute khusus subnet yang akan dihormati alih-alih rute default.

Jika memungkinkan, gunakan konfigurasi berikut:

  • Konfigurasi ExpressRoute mengiklankan 0.0.0.0/0 dan, secara default, memaksa terowongan semua lalu lintas keluar di tempat.
  • UDR yang diterapkan pada subnet yang berisi instans Azure Cache for Redis mendefinisikan 0.0.0.0/0 dengan rute kerja untuk lalu lintas TCP/IP ke internet publik. Misalnya, ini mengatur jenis hop berikutnya ke internet.

Efek gabungan dari langkah-langkah ini adalah bahwa UDR tingkat subnet lebih diutamakan daripada penerowongan paksa ExpressRoute dan yang memastikan akses internet keluar dari instans Azure Cache for Redis.

Menyambungkan ke instans Azure Cache for Redis dari aplikasi lokal dengan menggunakan ExpressRoute bukanlah skenario penggunaan yang khas karena alasan kinerja. Untuk performa terbaik, klien Azure Cache for Redis harus berada di wilayah yang sama dengan instans Azure Cache for Redis.

Penting

Rute yang ditentukan dalam UDR harus cukup spesifik untuk diutamakan atas rute apa pun yang ditampilkan oleh konfigurasi ExpressRoute. Contoh berikut menggunakan rentang alamat 0.0.0.0/0 yang luas dan, dengan demikian, dapat berpotensi secara tidak sengaja ditimpa oleh iklan rute yang menggunakan rentang alamat yang lebih spesifik.

Peringatan

Azure Cache for Redis tidak didukung dengan konfigurasi ExpressRoute yang salah mengiklankan rute dari jalur peering publik ke jalur peering pribadi. Konfigurasi ExpressRoute yang memiliki peering publik dikonfigurasi menerima iklan rute dari Microsoft untuk sekumpulan besar rentang alamat IP Microsoft Azure. Jika rentang alamat ini salah diiklankan secara silang di jalur peering pribadi, hasilnya adalah bahwa semua paket jaringan keluar dari subnet Azure Cache for Redis salah memasuki penerowongan paksa untuk infrastruktur jaringan lokal pelanggan. Aliran jaringan ini merusak Azure Cache for Redis. Solusi untuk masalah ini adalah menghentikan rute lintas iklan dari jalur peering publik ke jalur peering pribadi.

Informasi latar belakang tentang UDR tersedia di perutean lalu lintas jaringan Virtual.

Untuk informasi selengkapnya tentang ExpressRoute, lihat Gambaran umum teknis ExpressRoute.

Konten terkait

Pelajari lebih lanjut tentang fitur Azure Cache for Redis.