Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Azure Managed Redis adalah layanan Azure yang dikelola sepenuhnya berdasarkan Redis Enterprise. Ini menyediakan penyimpanan data dalam memori berperforma tinggi untuk aplikasi dan dirancang untuk beban kerja perusahaan yang memerlukan latensi sangat rendah, throughput tinggi, dan struktur data tingkat lanjut.
Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.
Artikel ini menjelaskan cara membuat Azure Managed Redis tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, dan pemadaman wilayah. Ini juga menjelaskan strategi pencadangan dan perjanjian tingkat layanan (SLA).
Rekomendasi penyebaran produksi
Untuk memastikan keandalan tinggi untuk instans Azure Managed Redis produksi Anda, kami sarankan Anda:
Menggunakan ketersediaan tinggi dengan menerapkan beberapa node untuk cache Anda.
Gunakan redundansi zona dengan menyebarkan cache yang sangat tersedia ke wilayah yang memiliki zona ketersediaan.
Pertimbangkan untuk menerapkan replikasi geografis aktif untuk beban kerja misi penting yang memerlukan failover lintas wilayah.
Gambaran umum arsitektur keandalan
Bagian ini menjelaskan beberapa aspek penting tentang cara kerja layanan yang paling relevan dari perspektif keandalan. Bagian ini memperkenalkan arsitektur logis, yang mencakup beberapa sumber daya dan fitur yang Anda sebarkan dan gunakan. Ini juga membahas arsitektur fisik, yang memberikan detail tentang cara kerja layanan di bawah sampul.
Arsitektur logika
Azure Managed Redis dibangun di Redis Enterprise dan memberikan keandalan melalui konfigurasi ketersediaan tinggi dan kemampuan replikasi.
Anda menerapkan sebuah instans Azure Managed Redis, yang juga dikenal sebagai sebuah instans cache atau sekadar cache. Aplikasi klien Anda menyimpan dan berinteraksi dengan data dalam cache dengan menggunakan API Redis.
Arsitektur fisik
Saat Anda merencanakan ketahanan di Azure Managed Redis, Anda harus memahami konsep utama simpul dan pecahan.
Node: Setiap instans cache terdiri dari node, yang merupakan komputer virtual (VM). Setiap VM berfungsi sebagai unit komputasi independen dalam kluster. Anda tidak melihat atau mengelola VM secara langsung. Platform secara otomatis membuat instans, memantau kesehatan instans, dan menggantikan instans apa pun yang menjadi tidak sehat. Set VM ini membentuk kluster.
Anda dapat menyiapkan instans untuk ketersediaan tinggi. Saat Anda menggunakan ketersediaan tinggi, Azure Managed Redis memastikan bahwa instans memiliki setidaknya dua simpul dan secara otomatis mereplikasi data di antaranya. Di wilayah yang memiliki zona ketersediaan, layanan menempatkan simpul ke zona ketersediaan yang berbeda. Untuk informasi selengkapnya, lihat Ketahanan terhadap kegagalan zona ketersediaan.
Layanan ini mengabstraksi jumlah node tertentu di setiap konfigurasi untuk menghindari kompleksitas dan memastikan konfigurasi yang optimal.
Pecahan: Setiap simpul menjalankan beberapa proses server Redis yang dikenal sebagai pecahan. Setiap shard mengelola subset data cache Anda. Saat Anda mengatur cache untuk ketersediaan tinggi, pecahan secara otomatis mendistribusikan dan mereplikasi di seluruh simpul. Anda menentukan kebijakan kluster, yang menentukan bagaimana pecahan didistribusikan di seluruh simpul.
Untuk informasi selengkapnya, lihat Arsitektur Azure Managed Redis dan Failover dan patching untuk Azure Managed Redis.
Ketahanan terhadap kesalahan sementara
Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.
Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.
Ikuti rekomendasi ini untuk mengelola kesalahan sementara saat Anda menggunakan Azure Managed Redis:
Gunakan konfigurasi SDK yang secara otomatis mencoba kembali ketika kesalahan sementara terjadi dan menerapkan periode backoff dan batas waktu yang sesuai. Pertimbangkan untuk menggunakan pola Coba Lagi dan pola Circuit Breaker di aplikasi Anda.
Mendesain pola cache-aside, di mana aplikasi Anda dapat terus beroperasi dengan performa yang menurun dengan kembali ke penyimpanan data utama ketika Redis tidak tersedia sementara.
Ketahanan terhadap kegagalan zona ketersediaan
Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.
Anda dapat membuat instans cache Azure Managed Redis bersifat redundan zona, yang secara otomatis mendistribusikan simpul cache ke beberapa zona ketersediaan dalam suatu wilayah. Redundansi zona mengurangi risiko bahwa pemadaman pusat data atau zona ketersediaan membuat cache Anda tidak tersedia.
Untuk membuat zona cache redundan, Anda harus menyebarkannya di wilayah yang didukung dan mengaturnya untuk menggunakan konfigurasi ketersediaan tinggi. Di wilayah tanpa zona ketersediaan, konfigurasi ketersediaan tinggi masih membuat setidaknya dua simpul, tetapi tidak ditempatkan di zona terpisah.
Diagram berikut ini menunjukkan cache yang memiliki redundansi zona dengan dua simpul, masing-masing di zona yang terpisah.
Persyaratan
Dukungan wilayah: Anda dapat menyebarkan cache Azure Managed Redis zona-redundan ke wilayah mana pun yang mendukung zona ketersediaan dan tempat layanan tersedia. Untuk daftar wilayah yang mendukung zona ketersediaan, lihat Wilayah Azure dengan zona ketersediaan. Untuk daftar wilayah yang mendukung Azure Managed Redis, lihat Ketersediaan produk menurut wilayah.
Konfigurasi ketersediaan tinggi: Anda harus menggunakan konfigurasi ketersediaan tinggi pada cache Anda agar zonanya redundan.
Tingkatan: Semua tingkatan Azure Managed Redis mendukung zona ketersediaan.
Biaya
Redundansi zona mengharuskan Anda untuk mengonfigurasi cache agar memiliki ketersediaan tinggi, dengan menerapkan minimal dua simpul pada cache Anda. Konfigurasi ketersediaan tinggi lebih mahal daripada konfigurasi ketersediaan non-tinggi. Untuk informasi selengkapnya, lihat Harga Azure Managed Redis.
Mengonfigurasi dukungan zona ketersediaan
Buat instans zona-redundan baru. Saat Anda membuat instans Azure Managed Redis baru, gunakan konfigurasi ketersediaan tinggi dan sebarkan ke wilayah yang mendukung zona ketersediaan. Instans mencakup redundansi zona secara default, tanpa konfigurasi tambahan yang diperlukan.
Untuk informasi selengkapnya, lihat Membuat instans Azure Managed Redis.
Buat zona instans yang ada menjadi redundan. Untuk membuat zona instans Azure Managed Redis yang ada menjadi redundan, sebarkan di wilayah yang mendukung zona ketersediaan dan siapkan ketersediaan tinggi pada cache.
Matikan redundansi zona. Anda tidak dapat menonaktifkan redundansi zona pada instans yang ada karena Anda tidak dapat membalikkan ketersediaan tinggi setelah menerapkannya ke cache.
Perencanaan dan manajemen kapasitas
Selama kejadian penurunan zona, instans Anda mungkin memiliki lebih sedikit sumber daya yang tersedia untuk melayani beban kerja Anda. Jika instans Anda sering mengalami tekanan sumber daya dan Anda perlu mempersiapkan kegagalan zona ketersediaan, pertimbangkan salah satu pendekatan berikut:
Lebihkan alokasi sumber daya untuk instans Anda. Pilih tingkat performa yang lebih tinggi dari yang Anda butuhkan sehingga instans Anda dapat mentolerir beberapa kehilangan kapasitas dan terus berfungsi tanpa penurunan performa. Untuk informasi selengkapnya, lihat Mengelola kapasitas dengan overprovisioning dan Menskalakan instans Azure Managed Redis.
Gunakan replikasi geografis aktif. Anda dapat menyebarkan beberapa instans di berbagai wilayah dan menyiapkan replikasi geografis aktif untuk menyebarkan beban Anda di seluruh instans terpisah tersebut.
Perilaku ketika semua zona sehat
Bagian ini menjelaskan apa yang diharapkan ketika cache Redis terkelola memiliki redundansi zonal dan semua zona ketersediaan berfungsi normal.
Pengaturan lalu lintas antar zona: Azure Managed Redis mendistribusikan shard di seluruh node berdasarkan kebijakan cluster Anda. Kebijakan kluster Anda juga menentukan bagaimana data mengalir ke setiap simpul. Redundansi zona tidak mengubah cara layanan merutekan lalu lintas.
Replikasi data antar zona: Azure Managed Redis secara otomatis mereplikasi pecahan di seluruh simpul dengan menggunakan replikasi asinkron. Anda biasanya mengukur lag replikasi antara pecahan dalam hitungan detik, tetapi durasi yang tepat tergantung pada beban kerja cache Anda. Skenario yang berat dalam penulisan dan berat dalam jaringan biasanya mengalami jeda replikasi yang lebih tinggi.
Perilaku selama kegagalan zona
Bagian ini menjelaskan apa yang diharapkan ketika cache Redis yang dikelola memiliki redundansi zona dan satu atau beberapa zona ketersediaan menjadi tidak tersedia:
- Deteksi dan respons: Azure Managed Redis bertanggung jawab untuk mendeteksi kegagalan di zona ketersediaan. Anda tidak perlu melakukan apa pun untuk memulai failover zona.
- Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.
Permintaan aktif: Layanan ini mungkin menghilangkan permintaan dalam penerbangan, dan aplikasi harus mencobanya kembali. Aplikasi harus menerapkan logika coba lagi untuk menangani gangguan sementara ini.
Kehilangan data yang diharapkan: Data apa pun yang belum direplikasi ke pecahan di zona lain mungkin hilang selama kegagalan zona. Anda biasanya mengukur jumlah kehilangan data dalam hitungan detik, tetapi tergantung pada jeda replikasi.
Waktu henti yang diharapkan: Sejumlah kecil waktu henti, biasanya sekitar 10 hingga 15 detik, mungkin terjadi saat potongan data beralih ke simpul di zona sehat. Untuk informasi selengkapnya tentang proses failover yang tidak direncanakan, lihat Penjelasan tentang failover. Saat Anda merancang aplikasi, ikuti praktik untuk penanganan kesalahan sementara.
Pengalihan lalu lintas: Azure Managed Redis secara otomatis mengalihkan lalu lintas ke simpul di zona sehat.
Pemulihan Zona
Saat zona ketersediaan yang terpengaruh pulih, Azure Managed Redis secara otomatis memulihkan operasi ke zona tersebut. Platform Azure sepenuhnya mengelola proses ini dan tidak memerlukan intervensi pelanggan.
Uji kegagalan zona
Azure Managed Redis sepenuhnya mengelola perutean lalu lintas jaringan, failover, dan failback untuk kegagalan zona ketersediaan, sehingga Anda tidak perlu menguji dan memvalidasi proses kegagalan zona ketersediaan atau memberikan masukan lebih lanjut.
Ketahanan terhadap kegagalan di seluruh wilayah
Azure Managed Redis menyediakan dukungan multi-wilayah asli melalui replikasi geografis aktif, yang memungkinkan Anda menautkan beberapa instans Azure Managed Redis di berbagai wilayah Azure ke dalam satu grup replikasi. Anda kemudian dapat menyiapkan pendekatan failover milik Anda sendiri di antara instance.
Replikasi Geo Aktif
Saat Anda menggunakan replikasi geografis aktif, aplikasi dapat membaca dari dan menulis ke instans cache apa pun dalam grup, dengan perubahan disinkronkan secara otomatis di semua wilayah. Layanan ini mendukung pola replikasi aktif-aktif di mana setiap wilayah dapat menangani operasi baca dan tulis secara bersamaan. Ketika konflik terjadi karena penulisan bersamaan di berbagai wilayah, layanan secara otomatis menyelesaikannya dengan menggunakan algoritma resolusi konflik yang telah ditentukan sebelumnya tanpa memerlukan intervensi manual. Pendekatan ini memberikan ketahanan terhadap kegagalan wilayah sambil mempertahankan akses latensi rendah untuk aplikasi yang didistribusikan secara global.
Diagram berikut menunjukkan dua instans cache di wilayah yang berbeda dalam grup geo-replikasi aktif yang sama, bersama dengan aplikasi klien yang terhubung ke setiap instans cache.
Anda bertanggung jawab untuk menyiapkan aplikasi klien Anda untuk mengalihkan permintaan ke instans sehat jika ada instans regional yang gagal. Diagram berikut menunjukkan bagaimana aplikasi dapat mengalihkan permintaan mereka ke instans cache yang sehat ketika instans yang biasanya mereka gunakan gagal.
Persyaratan
Dukungan wilayah: Anda dapat menyiapkan replikasi geografis aktif Azure Managed Redis antara wilayah Azure mana pun tempat layanan tersedia.
Konfigurasi instans: Replikasi geografis aktif memerlukan instans Azure Managed Redis yang menggunakan tingkat dan ukuran yang sama di setiap wilayah yang berpartisipasi. Semua instans cache dalam grup replikasi harus menggunakan pengaturan yang identik, termasuk opsi persistensi, modul, dan kebijakan pengklusteran.
Persyaratan lain: Instans cache Anda harus memenuhi persyaratan lain, termasuk modul yang Anda gunakan. Persyaratan ini memengaruhi bagaimana Anda dapat menskalakan instans cache Anda. Untuk informasi selengkapnya, lihat Prasyarat replikasi geografis aktif.
Pertimbangan
Tanggung jawab failover: Saat Anda menggunakan replikasi geografis aktif, Anda bertanggung jawab atas failover antar instans cache. Siapkan aplikasi Anda untuk menangani failover. Failover melibatkan persiapan dan mungkin mengharuskan Anda melakukan beberapa langkah. Untuk informasi selengkapnya, lihat Membatalkan tautan paksa selama pemadaman wilayah.
Konsistensi akhir: Merancang aplikasi untuk menangani skenario konsistensi akhir karena perubahan dapat memakan waktu untuk disebarluaskan di semua wilayah, tergantung pada kondisi jaringan dan jarak geografis. Selama pemadaman wilayah, Anda mungkin mengalami lebih banyak inkonsistensi data hingga konektivitas dipulihkan dan sinkronisasi selesai.
Biaya
Saat menyiapkan replikasi geografis aktif, Anda membayar untuk setiap instans Azure Managed Redis di setiap wilayah dalam grup replikasi. Anda mungkin juga dikenakan biaya transfer data untuk lalu lintas replikasi lintas wilayah antar wilayah. Untuk informasi selengkapnya, lihat Harga Azure Managed Redis dan Detail harga Bandwidth.
Mengonfigurasi dukungan multiregional
Buat instans cache baru yang direplikasi secara geografis. Siapkan replikasi geografis aktif saat Anda memprovisikan cache dengan menentukan grup replikasi dan menautkan beberapa instans. Untuk informasi selengkapnya, lihat Membuat atau bergabung dengan grup replikasi geografis aktif.
Tambahkan instans cache yang ada ke grup replikasi geografis. Anda dapat menambahkan instans cache yang ada ke grup replikasi geografis aktif.
Saat Anda menambahkan instans yang sudah ada ke grup replikasi geografis aktif, platform perlu menghapus data dalam instans tersebut, dan Anda akan mengalami sedikit gangguan waktu. Jika memungkinkan, rencanakan untuk menyiapkan replikasi geografis aktif saat Anda membuat instans cache.
Untuk informasi selengkapnya, lihat Menambahkan instans yang ada ke grup replikasi geografis aktif.
Nonaktifkan replikasi geografis pada instans cache. Hapus instans dari grup replikasi geografis dengan menghapus instans cache. Instans yang tersisa secara otomatis menyesuaikan pengaturannya.
Perencanaan dan manajemen kapasitas
Selama peristiwa wilayah tidak berfungsi, instans lain mungkin mengalami beban yang lebih tinggi. Jika instans sering berjalan mendekati batas sumber dayanya dan Anda harus mempersiapkan peningkatan persyaratan kapasitas selama kegagalan wilayah, pertimbangkan untuk menyediakan instans secara berlebihan. Untuk informasi selengkapnya, lihat Menskalakan instans Azure Managed Redis.
Perilaku ketika semua wilayah sehat
Bagian ini menjelaskan apa yang diharapkan saat Anda menyiapkan instans untuk menggunakan replikasi geografis aktif dan semua wilayah beroperasi secara normal.
Perutean lalu lintas antar wilayah: Anda bertanggung jawab untuk menyiapkan aplikasi Anda untuk terhubung ke instans cache tertentu. Aplikasi dapat terhubung ke instans cache apa pun di grup replikasi dan melakukan operasi baca dan tulis. Aplikasi ini mengelola pengaturan rute lalu lintas, yang memungkinkan Anda untuk mengarahkan klien ke wilayah terdekat untuk latensi minimal. Azure Managed Redis tidak secara otomatis merutekan lalu lintas antar wilayah.
Replikasi data antar wilayah: Layanan ini menggunakan replikasi asinkron antar wilayah untuk menjaga konsistensi akhir. Ini langsung mengeksekusi operasi penulisan di wilayah lokal dan kemudian menyebarkannya ke wilayah lain di latar belakang. Jenis data yang direplikasi bebas konflik (CRDT) memastikan bahwa layanan secara otomatis menggabungkan penulisan bersamaan di berbagai wilayah.
Perilaku selama kegagalan wilayah
Bagian ini menjelaskan apa yang diharapkan ketika Anda menyiapkan instans untuk menggunakan replikasi geografis aktif dan terjadi pemadaman di salah satu wilayah.
Deteksi dan respons: Anda bertanggung jawab untuk mendeteksi kegagalan instans cache dan memutuskan kapan harus melakukan failover. Anda dapat memantau kesehatan kluster yang direplikasi secara geografis, yang dapat membantu Anda memutuskan kapan harus memulai failover. Untuk informasi selengkapnya, lihat Metrik replikasi geografis.
Failover mengharuskan Anda melakukan beberapa langkah. Untuk informasi selengkapnya, lihat Membatalkan tautan paksa selama pemadaman wilayah.
Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.
Anda juga dapat memantau kesehatan setiap instans.
Untuk memantau kesehatan hubungan replikasi geografis, gunakan metrik sehat replikasi geografis . Metrik selalu memiliki nilai
1(sehat) atau0(tidak sehat). Siapkan pemberitahuan Azure Monitor pada metrik ini untuk mengidentifikasi kapan instans mungkin tidak sinkron.Permintaan aktif: Layanan mengakhiri permintaan ke wilayah yang gagal, dan logika failover aplikasi Anda harus menanganinya. Aplikasi harus menerapkan kebijakan coba lagi yang dapat mengalihkan lalu lintas ke cache yang sehat.
Kehilangan data yang diharapkan: Replikasi asinkron antar wilayah dapat mengakibatkan hilangnya penulisan terbaru ke wilayah yang gagal jika penulisan tersebut belum direplikasi ke wilayah lain. Jumlah potensi kehilangan data tergantung pada jeda replikasi pada saat kegagalan. Untuk informasi selengkapnya, lihat Redis terdistribusi geografis aktif-aktif dan Pertimbangan tentang konsistensi dan kehilangan data dalam kegagalan regional pada database yang direplikasi bebas konflik (CRDB).
Waktu henti yang diharapkan: Aplikasi mengalami waktu henti hanya selama durasi yang diperlukan untuk mendeteksi kegagalan dan mengalihkan lalu lintas ke wilayah yang sehat. Waktu henti ini biasanya berkisar dari detik hingga beberapa menit dan bergantung pada cara Anda menyiapkan konfigurasi pemeriksaan kesehatan dan failover aplikasi Anda.
Pengalihan lalu lintas: Anda bertanggung jawab untuk menerapkan logika di aplikasi Anda untuk mendeteksi kegagalan wilayah dan merutekan lalu lintas ke wilayah yang sehat. Anda dapat menerapkan logika ini melalui pemeriksaan kesehatan, pola pemutus sirkuit, atau solusi penyeimbangan beban eksternal.
Pemulihan wilayah
Saat wilayah yang gagal pulih, Azure Managed Redis secara otomatis mengintegrasi ulang instans di wilayah tersebut ke dalam grup replikasi geografis aktif tanpa intervensi Anda. Layanan ini secara otomatis menyinkronkan data dari instance yang berfungsi dengan baik. Selama proses ini, instans yang dipulihkan secara bertahap menyinkronkan perubahan yang terjadi selama pemadaman. Setelah sinkronisasi selesai, instans yang dipulihkan menjadi sepenuhnya aktif dan dapat menangani operasi baca dan tulis.
Anda bertanggung jawab untuk mengonfigurasi ulang aplikasi Anda untuk merutekan lalu lintas kembali ke instans wilayah yang dipulihkan.
Pengujian untuk mendeteksi kegagalan wilayah
Uji prosedur failover aplikasi Anda secara teratur. Aplikasi Anda harus dapat melakukan failover antar instans dan memenuhi persyaratan bisnis Anda untuk waktu henti selama transisi. Uji juga proses respons Anda secara keseluruhan, termasuk konfigurasi ulang firewall dan infrastruktur lainnya, dan proses pemulihan Anda.
Ketahanan terhadap pemeliharaan layanan
Azure Managed Redis menangani peningkatan layanan reguler dan tugas pemeliharaan lainnya.
Selama pemeliharaan, Azure Managed Redis secara otomatis membuat simpul baru dan failover. Aplikasi klien mungkin mengalami gangguan koneksi dan kesalahan sementara lainnya. Aplikasi harus menerapkan logika coba lagi untuk menangani gangguan sementara ini.
Untuk informasi selengkapnya tentang proses pemeliharaan Azure Managed Redis, lihat Failover dan patching untuk Azure Managed Redis.
Pencadangan dan pemulihan
Azure Managed Redis menyediakan kemampuan persistensi data dan pencadangan untuk melindungi dari skenario kehilangan data yang mungkin tidak diatasi oleh fitur keandalan lainnya. Pencadangan melindungi dari skenario seperti kerusakan data, penghapusan yang tidak disengaja, atau kesalahan konfigurasi.
Persistensi data: Secara default, Azure Managed Redis menyimpan semua data cache dalam memori. Layanan ini dapat secara opsional menulis rekam jepret data Anda ke disk dengan menggunakan persistensi data. Jika kegagalan perangkat keras memengaruhi simpul, Azure Managed Redis secara otomatis memulihkan data. Anda dapat memilih dari berbagai jenis persistensi data, yang menyediakan trade-off yang berbeda antara frekuensi rekam jepret dan efek performa pada cache Anda.
Anda tidak dapat memulihkan file data ke instans lain, dan Anda tidak dapat mengakses file. Persistensi data tidak melindungi Anda dari kerusakan data atau penghapusan yang tidak disengaja.
Impor dan ekspor: Azure Managed Redis mendukung pencadangan data Anda saat Anda menggunakan fungsi impor dan ekspor, yang menyimpan file cadangan ke Azure Blob Storage. Anda dapat menyiapkan penyimpanan geo-redundan (GRS) di akun Azure Storage Anda di wilayah yang didukung, atau Anda dapat menyalin atau memindahkan blob cadangan ke lokasi lain untuk perlindungan lebih lanjut.
Anda dapat memulihkan file yang diekspor ke instans cache yang sama atau instans cache yang berbeda.
Layanan ini tidak menyertakan penjadwal impor atau ekspor bawaan, tetapi Anda dapat mengembangkan proses otomatisasi Anda sendiri yang menggunakan Azure CLI atau Azure PowerShell untuk memulai operasi ekspor.
Perjanjian tingkat layanan
Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.
SLA untuk Azure Managed Redis mencakup konektivitas ke titik akhir cache. Ini tidak mencakup perlindungan dari kehilangan data.
Agar memenuhi syarat untuk ketersediaan SLA untuk Azure Managed Redis, Anda harus memenuhi persyaratan berikut:
Anda harus menggunakan konfigurasi ketersediaan tinggi.
Anda tidak boleh memulai fitur pada produk atau tindakan pengelolaan apa pun yang didokumentasikan untuk menghasilkan ketidaktersediaan sementara.
Perjanjian Tingkat Layanan (SLA) ketersediaan yang lebih tinggi berlaku saat instans Anda redundan di zona. Dalam beberapa tingkatan, Anda dapat memenuhi syarat untuk SLA ketersediaan yang lebih tinggi saat Anda menyebarkan instans redundan zona ke setidaknya tiga wilayah dengan menggunakan replikasi geografis aktif.