Keandalan di Azure Managed Redis

Azure Managed Redis menyediakan Redis Enterprise yang terintegrasi penuh dan dikelola di Azure, menawarkan penyimpanan data dalam memori berkinerja tinggi untuk aplikasi. Layanan ini dibangun untuk beban kerja perusahaan yang membutuhkan latensi ultra 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 keandalan di Azure Managed Redis, termasuk ketahanan terhadap kesalahan sementara, kegagalan zona ketersediaan, dan kegagalan di seluruh wilayah. Artikel 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:

• Aktifkan ketersediaan tinggi, yang menyebarkan beberapa simpul untuk cache Anda.
• Aktifkan redundansi zona dengan menyebarkan cache yang sangat tersedia ke wilayah dengan 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 logis

Azure Managed Redis dibangun di Redis Enterprise dan memberikan keandalan melalui konfigurasi ketersediaan tinggi dan kemampuan replikasi.

Anda menerapkan instans Azure Managed Redis, yang juga disebut instans cache atau cache. Aplikasi klien Anda menyimpan dan berinteraksi dengan data dalam cache dengan menggunakan API Redis.

Arsitektur fisik

Ada dua konsep utama yang perlu Anda pahami saat merencanakan ketahanan untuk Azure Managed Redis: 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 ini secara otomatis mengelola pembuatan instans, pemantauan kesehatan, dan penggantian instans yang tidak sehat. Set VM, yang digabungkan, juga disebut kluster.

  Anda dapat mengonfigurasi instans untuk ketersediaan tinggi. Saat Anda melakukannya, Azure Managed Redis memastikan bahwa setidaknya ada dua simpul, dan mereplikasi data antara simpul secara otomatis. Di wilayah dengan zona ketersediaan, simpul-simpul ditempatkan di zona ketersediaan yang berbeda. Untuk informasi selengkapnya, lihat Ketahanan terhadap kegagalan zona ketersediaan.

  Layanan ini mengabstraksi jumlah node tertentu yang digunakan dalam setiap konfigurasi untuk menghindari kompleksitas dan memastikan konfigurasi yang optimal.

• Pecahan: Setiap simpul menjalankan beberapa proses server Redis yang disebut pecahan, yang mengelola sekumpulan data cache Anda. Saat cache Anda dikonfigurasi untuk ketersediaan tinggi, shard secara otomatis didistribusikan dan direplikasi di seluruh node. Anda menentukan kebijakan kluster, yang menentukan bagaimana shard 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 menggunakan Azure Managed Redis:

• Gunakan konfigurasi SDK yang secara otomatis mencoba kembali saat kesalahan sementara terjadi, dan yang menggunakan periode backoff dan batas waktu yang sesuai. Pertimbangkan untuk menggunakan pola Coba Lagi dan pola Circuit Breaker di aplikasi Anda.
• Desain untuk pola cache-aside di mana aplikasi Anda dapat terus beroperasi dengan performa yang menurun ketika Redis sementara tidak tersedia dengan beralih kembali ke penyimpanan data utama.

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.

Instans cache Azure Managed Redis dapat dibuat redundan zona, yang secara otomatis mendistribusikan simpul cache di beberapa zona ketersediaan dalam suatu wilayah. Redundansi zona mengurangi risiko pemadaman pusat data atau zona ketersediaan yang menyebabkan cache Anda tidak tersedia.

Untuk membuat zona cache yang redundan, Anda harus menerapkannya di wilayah yang didukung dan mengaktifkan konfigurasi ketersediaan tinggi. Di wilayah tanpa zona ketersediaan, konfigurasi ketersediaan tinggi masih membuat setidaknya dua simpul tetapi tidak berada di zona terpisah.

Diagram berikut menunjukkan cache zona-redundan dengan dua simpul, masing-masing berada di zona terpisah.

Persyaratan

• Dukungan wilayah: Cache Azure Managed Redis dengan redundansi zona dapat disebarkan ke wilayah mana pun yang mendukung zona ketersediaan dan di mana layanan tersedia. Untuk daftar wilayah terbaru 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 mengaktifkan konfigurasi ketersediaan tinggi pada cache Anda agar memiliki redundansi zona.

• Tingkatan: Semua tingkatan Azure Managed Redis mendukung zona ketersediaan.

Biaya

Redundansi zona mengharuskan bahwa cache Anda dikonfigurasi untuk ketersediaan tinggi, yang berarti menyebarkan sedikitnya dua simpul untuk cache Anda. Konfigurasi dengan ketersediaan tinggi dikenakan tarif yang lebih tinggi daripada konfigurasi dengan ketersediaan standar. 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, aktifkan konfigurasi ketersediaan tinggi dan sebarkan ke wilayah dengan zona ketersediaan. Kemudian, secara otomatis menyertakan redundansi zona secara default. Anda tidak perlu melakukan konfigurasi lagi.

  Untuk langkah-langkah mendetail, lihat Mulai Cepat: Membuat Instans Azure Managed Redis.

• Aktifkan redundansi zona pada instans yang ada: Untuk mengonfigurasi instans Azure Managed Redis yang ada menjadi redundansi zona, pastikan instans tersebut disebarkan di wilayah yang mendukung zona ketersediaan, dan aktifkan ketersediaan tinggi pada cache.

• Nonaktifkan redundansi zona: Redundansi zona tidak dapat dinonaktifkan pada instans yang ada, karena Anda tidak dapat menonaktifkan ketersediaan tinggi setelah diaktifkan pada instans 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 berada di bawah tekanan sumber daya dan Anda perlu mempersiapkan kegagalan zona ketersediaan, pertimbangkan salah satu pendekatan berikut:

• Provisi instans Anda secara berlebihan: Provisi berlebih melibatkan pemilihan tingkat performa yang lebih tinggi dari yang mungkin Anda perlukan. Ini memungkinkan instans Anda untuk mentolerir beberapa kehilangan kapasitas dan terus berfungsi tanpa penurunan performa. Untuk informasi selengkapnya tentang prinsip provisi berlebih, lihat Mengelola kapasitas dengan provisi berlebih. Untuk mempelajari cara menskalakan instans Anda, lihat Menskalakan instans Azure Managed Redis.

• Gunakan replikasi geografis aktif: Anda dapat menyebarkan beberapa instans di berbagai wilayah, dan mengonfigurasi 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 bersifat redundan dan semua zona-zona ketersediaan beroperasi:

• Perutean lalu lintas antar zona: Shard didistribusikan di seluruh simpul berdasarkan kebijakan kluster Anda. Kebijakan kluster Anda juga menentukan bagaimana lalu lintas dirutekan ke setiap simpul. Redundansi zona tidak mengubah cara lalu lintas dirutekan.

• Replikasi data antar zona: Shard direplikasi di seluruh simpul secara otomatis, dan menggunakan replikasi asinkron. Biasanya jeda replikasi antara pecahan diukur dalam hitungan detik, tetapi itu dapat bervariasi tergantung pada beban kerja cache, dengan skenario yang banyak menulis dan banyak lalu lintas jaringan biasanya mengalami jeda replikasi yang lebih tinggi.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang dapat diharapkan ketika cache Redis yang dikelola bersifat redundan zona dan satu atau beberapa zona ketersediaan 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: Permintaan dalam penerbangan mungkin dihilangkan dan harus dicoba 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. Biasanya jumlah kehilangan data diukur dalam hitungan detik, tetapi tergantung pada jeda replikasi.

• Waktu henti yang diharapkan: Sejumlah kecil waktu henti, biasanya 10-15 detik, mungkin terjadi saat pecahan berpindah ke node di zona sehat. Untuk informasi 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

Karena Azure Managed Redis sepenuhnya mengelola perutean lalu lintas, failover, dan failback terkait kegagalan zona, Anda tidak perlu memeriksa proses kegagalan zona ketersediaan atau memberikan input 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 mengonfigurasi pendekatan failover Anda sendiri antara instans-instans.

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 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 replikasi geografis aktif yang sama, dengan aplikasi klien yang terhubung ke setiap instans cache:

Anda bertanggung jawab untuk mengonfigurasi aplikasi klien Anda sehingga, jika ada instans regional yang gagal, mereka dapat mengalihkan permintaan mereka ke instans yang sehat. Diagram berikut menunjukkan bagaimana aplikasi dapat mengalihkan permintaan mereka ke instans cache yang sehat ketika instans yang biasanya mereka gunakan gagal:

Persyaratan

• Dukungan wilayah Replikasi geografis aktif Azure Managed Redis dapat dikonfigurasi antara wilayah Azure mana pun tempat layanan tersedia.

• Konfigurasi instans: Replikasi geografis aktif memerlukan instans Azure Managed Redis dengan tingkat dan ukuran yang sama di semua wilayah yang berpartisipasi. Semua instans cache dalam grup replikasi harus dikonfigurasi dengan pengaturan yang identik termasuk opsi persistensi, modul, dan kebijakan pengklusteran.

• Persyaratan lain: Instans cache Anda harus memenuhi persyaratan lain, termasuk modul yang Anda gunakan, dan memengaruhi bagaimana instans cache Anda dapat diskalakan. 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. Anda harus menyiapkan dan mengonfigurasi aplikasi Anda untuk menangani failover. Failover melibatkan persiapan dan mungkin mengharuskan Anda menyelesaikan beberapa langkah. Untuk informasi selengkapnya, lihat Membatalkan tautan paksa jika ada pemadaman wilayah.

• Konsistensi akhir: Aplikasi harus dirancang 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 mengaktifkan replikasi geografis aktif, Anda akan ditagih untuk setiap instans Azure Managed Redis di setiap wilayah dalam grup replikasi. Selain itu, Anda mungkin dikenakan biaya transfer data untuk lalu lintas replikasi lintas wilayah antar wilayah. Untuk informasi selengkapnya tentang harga, lihat Harga Azure Managed Redis dan Detail harga Bandwidth.

Mengonfigurasi dukungan multiregional

• Membuat instans cache geo-replikasi baru: Mengonfigurasi replikasi geografis aktif selama provisi cache dengan menentukan grup replikasi dan menautkan beberapa instans. Untuk informasi selengkapnya, lihat Membuat atau bergabung dengan grup replikasi geografis aktif.

• Aktifkan instans cache yang ada untuk replikasi geografis: Anda dapat menambahkan instans cache yang ada ke grup replikasi geografis aktif.

  Namun, ketika instans yang ada ditambahkan ke grup replikasi geografis aktif, data dalam instans perlu dibersihkan, dan ada sedikit waktu henti. Jika memungkinkan, rencanakan untuk mengaktifkan 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 mengonfigurasi ulang sendiri.

Perencanaan dan manajemen kapasitas

Selama kejadian gangguan wilayah, instans lain mungkin berada di bawah tekanan yang lebih tinggi. Jika instans sering kali berada di bawah tekanan sumber daya dan Anda perlu mempersiapkan peningkatan persyaratan kapasitas selama kegagalan wilayah, pertimbangkan untuk menyediakan instans secara berlebihan. Untuk mempelajari cara menskalakan instans, lihat Menskalakan instans Azure Managed Redis.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika instans dikonfigurasi untuk menggunakan replikasi geografis aktif dan semua wilayah beroperasi.

• Perutean lalu lintas antar wilayah: Anda bertanggung jawab untuk mengonfigurasi 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. Perutean lalu lintas ditangani oleh aplikasi, memungkinkan Anda mengarahkan klien ke wilayah terdekat untuk latensi minimal. Azure Managed Redis tidak menyediakan perutean lalu lintas otomatis antar wilayah.

• Replikasi data antar wilayah: Layanan menggunakan replikasi asinkron antar wilayah untuk menjaga konsistensi akhir. Operasi tulis segera dilakukan di wilayah lokal dan kemudian disebarluaskan ke wilayah lain di latar belakang. Jenis data yang direplikasi bebas konflik (CRDT) memastikan bahwa penulisan bersamaan di berbagai wilayah secara otomatis digabungkan.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika instans dikonfigurasi untuk menggunakan replikasi geografis aktif dan ada pemadaman di 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 detail selengkapnya, lihat Membatalkan tautan paksa jika ada 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 mengawasi keberlangsungan hubungan replikasi geografis, Anda dapat menggunakan metrik Geo-replikasi sehat. Metrik selalu memiliki nilai 1 (sehat) atau 0 (tidak sehat). Anda dapat mengonfigurasi pemberitahuan Azure Monitor pada metrik ini untuk memahami kapan instans mungkin tidak sinkron.

• Permintaan aktif: Permintaan ke wilayah yang gagal dihentikan dan harus ditangani oleh logika failover aplikasi Anda. Aplikasi harus menerapkan kebijakan coba lagi yang dapat mengalihkan lalu lintas ke cache yang sehat.

• Kehilangan data yang diharapkan: Karena replikasi asinkron antar wilayah, beberapa penulisan terbaru ke wilayah yang gagal mungkin hilang jika belum direplikasi ke wilayah lain. Jumlah potensi kehilangan data tergantung pada jeda replikasi pada saat kegagalan. Untuk informasi selengkapnya, lihat Active-Active geo-distributed Redis dan Pertimbangan tentang Konsistensi dan Kehilangan Data dalam Kegagalan Regional 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. Ini biasanya berkisar dari detik hingga beberapa menit, tergantung pada bagaimana Anda telah mengonfigurasi 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. Ini dapat dicapai 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 memerlukan intervensi Anda. Layanan secara otomatis menyinkronkan data dari instance yang sehat. Selama proses ini, instance yang dipulihkan secara bertahap mengejar 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

Anda harus menguji prosedur failover aplikasi Anda secara teratur. Penting bahwa aplikasi Anda dapat mengalihkan failover di antara instans, dan tetap memenuhi persyaratan bisnis Anda untuk downtime saat melakukannya. Penting juga bahwa Anda menguji proses respons keseluruhan, termasuk konfigurasi ulang firewall dan infrastruktur lainnya, dan proses pemulihan Anda.

Ketahanan terhadap pemeliharaan layanan

Azure Managed Redis melakukan peningkatan layanan reguler dan tugas pemeliharaan lainnya.

Saat pemeliharaan sedang berlangsung, Azure Managed Redis secara otomatis melakukan pembuatan simpul baru dan melakukan failover secara otomatis. Aplikasi klien mungkin melihat gangguan koneksi dan kesalahan sementara lainnya. Aplikasi harus menerapkan logika coba lagi untuk menangani gangguan sementara ini.

Untuk informasi lebih lanjut mengenai proses pemeliharaan untuk Azure Managed Redis, silakan 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 dapat memberikan perlindungan terhadap skenario seperti kerusakan data, penghapusan yang tidak disengaja, atau kesalahan konfigurasi.

• Persistensi data: Secara default, Azure Managed Redis menyimpan semua data cache dalam memori. Ini dapat secara opsional menulis rekam jepret data Anda ke disk dengan menggunakan persistensi data. Jika ada kegagalan perangkat keras yang memengaruhi simpul, Azure Managed Redis secara otomatis memulihkan data. Ada berbagai jenis persistensi data yang dapat Anda pilih, yang memberikan tradeoff yang berbeda antara frekuensi rekam jepret dan efek performa pada cache Anda.

  Namun, file data tidak dapat dipulihkan 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 dengan menggunakan fungsionalitas impor dan ekspor, yang menyimpan file cadangan ke Azure Blob Storage. Anda dapat mengonfigurasi penyimpanan geo-redundan di akun Azure Storage Anda, atau Anda dapat menyalin atau memindahkan blob cadangan ke lokasi lain untuk perlindungan lebih lanjut.

  File yang diekspor dapat dipulihkan ke instans cache yang sama atau instans cache yang berbeda.

  Tidak ada 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. SLA tidak mencakup perlindungan dari kehilangan data.

Agar memenuhi syarat untuk ketersediaan SLA untuk Azure Managed Redis:

• Anda harus mengaktifkan konfigurasi ketersediaan tinggi.
• Anda tidak boleh memulai fitur pada produk atau tindakan pengelolaan apa pun yang didokumentasikan untuk menghasilkan ketidaktersediaan sementara.

SLA ketersediaan yang lebih tinggi berlaku ketika instans Anda memiliki redundansi zona. Dalam beberapa tingkatan, Anda dapat memenuhi syarat untuk SLA ketersediaan yang lebih tinggi ketika Anda telah menyebarkan instans redundan zona ke setidaknya tiga wilayah menggunakan replikasi geografis aktif.