Ketersediaan tinggi dan pemulihan bencana
Seperti halnya sistem cloud apa pun, waktu henti yang tidak direncanakan dapat terjadi yang mengakibatkan instans mesin virtual (VM), Availability Zone, atau wilayah Azure lengkap berhenti beroperasi. Kami merekomendasikan pelanggan memiliki rencana untuk menangani waktu henti zona atau regional.
Artikel ini menyajikan informasi bagi pelanggan untuk membuat rencana kelangsungan bisnis dan pemulihan bencana untuk implementasi Azure Cache for Redis, atau Azure Cache for Redis Enterprise mereka.
Berbagai opsi ketersediaan tinggi tersedia di tingkat Standar, Premium, dan Perusahaan:
| Opsi | Deskripsi | Ketersediaan | Standar | Premium | Perusahaan |
|---|---|---|---|---|---|
| Replikasi standar | Konfigurasi tereplikasi simpul-ganda dalam satu pusat data dengan failover otomatis | 99.9% (lihat rincian) | Ya | Ya | Ya |
| Zona redundansi | Konfigurasi multi-simpul direplikasi di seluruh Availability Zone, dengan failover otomatis | 99,9% pada Premium; 99,99% di Enterprise (lihat detailnya) | Ya (Pratinjau) | Ya | Ya |
| Replikasi lokasi geografis | Instans cache tertaut di dua wilayah, dengan kegagalan yang dikontrol pengguna | Premium; Enterprise (lihat detailnya) | No | Pasif | Aktif |
| Import/Export | Snapshot data titik waktu dalam cache. | 99.9% (lihat rincian) | Tidak | Ya | Ya |
| Persistensi | Penyimpanan data berkala ke akun penyimpanan. | 99.9% (lihat rincian) | Tidak | Ya | Pratinjau |
Replikasi standar untuk ketersediaan tinggi
Tingkatan yang berlaku: Standar, Premium, Enterprise, Enterprise Flash
Disarankan untuk: Ketersediaan tinggi
Azure Cache for Redis memiliki arsitektur ketersediaan tinggi yang memastikan instans terkelola Anda berfungsi, bahkan ketika pemadaman memengaruhi komputer virtual (VM) yang mendasar. Apakah pemadaman direncanakan atau tidak direncanakan, Azure Cache for Redis memberikan tingkat ketersediaan persentase yang lebih besar daripada yang dapat dicapai dengan menghosting Redis pada satu VM.
Azure Cache for Redis di tingkat yang berlaku berjalan pada sepasang server Redis secara default. Dua server dihosting pada komputer virtual khusus. Redis sumber terbuka hanya memungkinkan satu server untuk menangani permintaan penulisan data.
Dengan Azure Cache for Redis, satu server adalah simpul utama, sedangkan yang lain adalah replika. Setelah memprovisikan node kluster, Azure Cache for Redis menetapkan peran utama dan replika kepada mereka. Simpul utama biasanya bertanggung jawab untuk melayani permintaan tulis dan baca dari klien Redis. Pada operasi tulis, ia menerapkan kunci baru dan pembaruan kunci ke memori internalnya dan segera membalas klien. Ini meneruskan operasi ke replika secara asinkron.
Catatan
Biasanya, aplikasi klien Azure Cache for Redis berkomunikasi dengan simpul utama dalam cache untuk semua permintaan baca dan tulis. Klien Redis tertentu dapat dikonfigurasikan untuk membaca dari simpul replika.
Jika simpul utama dalam cache tidak tersedia, replika secara otomatis mempromosikan dirinya sendiri untuk menjadi primer baru. Proses ini disebut kegagalan. Failover hanya dua node, primer/replika, peran trading, replika/primer, dengan salah satu node mungkin akan offline selama beberapa menit. Di sebagian besar failover, node utama dan replika mengoordinasikan penyerahan sehingga Anda memiliki waktu hampir nol tanpa primer.
Mantan primer offline secara singkat untuk menerima pembaruan dari primer baru. Kemudian, replika sekarang kembali online dan bergabung kembali dengan cache yang sepenuhnya disinkronkan. Kuncinya adalah bahwa ketika node tidak tersedia, itu adalah kondisi sementara dan kembali online.
Urutan failover umum terlihat seperti ini, ketika primer perlu turun untuk pemeliharaan:
- Node primer dan replika menegosiasikan peran failover dan perdagangan terkoordinasi.
- Replika (sebelumnya utama) offline untuk boot ulang.
- Beberapa detik atau menit kemudian, replika kembali online.
- Replika menyinkronkan data dari primer.
Simpul utama dapat keluar dari layanan sebagai bagian dari aktivitas pemeliharaan yang direncanakan, seperti perangkat lunak Redis atau pembaruan sistem operasi. Ia juga dapat berhenti bekerja karena peristiwa yang tidak direncanakan seperti kegagalan dalam perangkat keras, perangkat lunak, atau jaringan yang mendasarinya. Failover dan patch untuk Azure Cache for Redis memberikan penjelasan terperinci tentang jenis failover Redis. Azure Cache for Redis melewati banyak kegagalan selama masa hidupnya. Desain arsitektur ketersediaan tinggi membuat perubahan ini di dalam cache setransparan mungkin bagi kliennya.
Selain itu, Azure Cache for Redis menyediakan lebih banyak simpul replika di tingkat Premium. Cache multi-replika dapat dikonfigurasikan dengan hingga tiga simpul replika. Memiliki lebih banyak replika umumnya meningkatkan ketahanan karena Anda memiliki simpul yang mencadangkan yang utama. Bahkan dengan lebih banyak replika, instans Azure Cache for Redis masih dapat sangat terpengaruh oleh pusat data atau pemadaman Zona Ketersediaan. Anda dapat meningkatkan ketersediaan cache dengan menggunakan beberapa replika dengan redundansi zona.
Redundansi zona
Tingkat yang berlaku: Standar (pratinjau), Premium, Enterprise, Enterprise Flash
Direkomendasikan untuk: Ketersediaan tinggi, Pemulihan bencana - wilayah intra
Azure Cache for Redis mendukung konfigurasi redundansi zona di tingkat Standar (pratinjau), Premium, dan Enterprise. Sebuah cache redundansi zona dapat menempatkan simpulnya di berbagai Zona Ketersediaan Azure dalam wilayah yang sama. Ini menghilangkan pusat data atau waktu henti Availability Zone sebagai satu titik kegagalan dan meningkatkan ketersediaan keseluruhan cache Anda.
Catatan
Pada cache Premium, hanya alokasi zona otomatis yang ada di pratinjau publik. Pemilihan zona ketersediaan manual yang tidak kita ubah. Pilihan manual adalah GA (Ketersediaan Umum).
Jika cache dikonfigurasi untuk menggunakan dua zona atau lebih seperti yang dijelaskan sebelumnya dalam artikel, simpul cache dibuat di zona yang berbeda. Saat zona berhenti beroperasi, simpul cache di zona lain tersedia untuk menjaga cache berfungsi seperti biasa.
Penting
Anda sekarang dapat mengaktifkan alokasi zona otomatis untuk semua cache di tingkat dan wilayah yang berlaku. Untuk informasi selengkapnya, lihat Mengaktifkan redundansi zona untuk Azure Cache for Redis.
Tingkat premium
Diagram berikut mengilustrasikan konfigurasi redundansi zona untuk tingkat Premium:
Azure Cache for Redis mendistribusikan simpul dalam cache zona redundan dengan cara round-robin melalui Availability Zone yang Anda pilih. Ini juga menentukan node yang berfungsi sebagai yang utama pada awalnya.
Pengalaman Zona Tidak Berfungsi untuk tingkat Premium
Cache berlebihan dalam zona menyediakan failover otomatis. Ketika simpul utama saat ini tidak tersedia, salah satu replika mengambil alih. Aplikasi Anda mungkin mengalami waktu respons cache yang lebih tinggi jika simpul utama baru terletak di AZ yang berbeda. Availability Zone terpisah secara geografis. Beralih dari satu AZ ke AZ lain mengubah jarak fisik antara tempat aplikasi dan cache Anda dihosting. Perubahan ini berdampak pada keterlambatan jaringan pulang-pergi dari aplikasi Anda ke cache. Latensi ekstra diharapkan berada dalam rentang yang dapat diterima untuk sebagian besar aplikasi. Kami sarankan Anda menguji aplikasi Anda untuk memastikannya berjalan dengan baik dengan cache dengan zona berlebihan.
Tingkatan Enterprise dan Enterprise Flash
Cache di salah satu tingkat Enterprise berjalan pada kluster Enterprise Redis. Ia selalu memerlukan node kluster dalam jumlah ganjil untuk membentuk kuorum. Secara default, ia memiliki tiga simpul, masing-masing dihosting pada komputer virtual khusus.
- Cache Enterprise memiliki dua simpul data berukuran sama dan satu simpul kuorum yang lebih kecil.
- Cache Enterprise Flash memiliki tiga simpul data berukuran sama.
Kluster Enterprise membagi data Redis menjadi partisi-partisi secara internal. Setiap partisi memiliki satu utama dan setidaknya satu replika. Setiap simpul data memegang satu atau beberapa partisi. Kluster Enterprise memastikan bahwa partisi yang utama dan replika apa pun tidak pernah dikolokasikan pada simpul data yang sama. Partisi mereplikasi data secara asinkron dari yang utama ke replika yang sesuai.
Pengalaman Zona Tidak Berfungsi untuk tingkat Perusahaan
Ketika simpul data menjadi tidak tersedia atau pemisahan jaringan terjadi, kegagalan yang mirip dengan yang dijelaskan dalam Replikasi standar terjadi. Kluster Enterprise menggunakan model berbasis kuorum untuk menentukan simpul yang bertahan mana yang berpartisipasi dalam kuorum baru. Ini juga mempromosikan partisi replika dalam simpul ini ke yang utama sesuai kebutuhan.
Ketersediaan regional
Cache tingkat Premium zona-redundan tersedia di wilayah berikut:
| Amerika | Eropa | Timur Tengah | Afrika | Asia Pasifik |
|---|---|---|---|---|
| Brasil Selatan | Prancis Tengah | Qatar Tengah | Afrika Selatan Utara | Australia Timur |
| Kanada Tengah | Jerman Barat Tengah | India Tengah | ||
| US Tengah | Eropa Utara | Jepang Timur | ||
| AS Timur | Norwegia Timur | Korea Tengah | ||
| AS Timur 2 | UK Selatan | Asia Tenggara | ||
| US Tengah Selatan | Eropa Barat | Asia Timur | ||
| US Gov Virginia | Swedia Tengah | Tiongkok Utara 3 | ||
| US Barat 2 | Swiss Utara | |||
| AS Barat 3 | Polandia Tengah |
Cache tingkat Enterprise dan Enterprise Flash zona-redundan tersedia di wilayah berikut:
| Amerika | Eropa | Timur Tengah | Afrika | Asia Pasifik |
|---|---|---|---|---|
| Kanada Tengah* | Eropa Utara | Australia Timur | ||
| US Tengah* | UK Selatan | India Tengah | ||
| US Timur | Eropa Barat | Asia Tenggara | ||
| AS Timur 2 | Jepang Timur* | |||
| US Tengah Selatan | Asia Timur* | |||
| US Barat 2 | ||||
| AS Barat 3 | ||||
| Brasil Selatan |
* Tingkat Enterprise Flash tidak tersedia di wilayah ini.
Penyebaran ulang dan migrasi zona ketersediaan
Saat ini, satu-satunya cara untuk mengonversi cache Anda dari konfigurasi non-AZ ke konfigurasi AZ adalah dengan menyebarkan ulang cache. Untuk mempelajari cara menyebarkan ulang cache Anda saat ini, lihat Memigrasikan instans Azure Cache for Redis ke dukungan zona ketersediaan.
Persistensi
Tingkatan yang berlaku: Premium, Enterprise (pratinjau), Enterprise Flash (pratinjau)
Direkomendasikan untuk: Durabilitas data
Karena data cache Anda disimpan dalam memori, kegagalan beberapa simpul yang langka dan tidak direncanakan dapat menyebabkan semua data dijatuhkan. Untuk menghindari kehilangan data sepenuhnya, persistensi Redis memungkinkan Anda untuk mengambil snapshot berkala dari data dalam memori, dan menyimpannya ke akun penyimpanan Anda. Jika Anda mengalami kegagalan di beberapa simpul yang menyebabkan kehilangan data, cache Anda memuat snapshot dari akun penyimpanan. Untuk informasi selengkapnya, lihat Mengonfigurasi persistensi data untuk Azure Cache for Redis Premium.
Akun penyimpanan memperhitungkan persistensi
Pertimbangkan untuk memilih akun penyimpanan geo-redundan untuk memastikan ketersediaan tinggi untuk data persisten Anda. Untuk informasi lebih lanjut, lihat Redundansi Azure Storage.
Import/Export
Tingkatan yang berlaku: Premium, Enterprise, Enterprise Flash
Direkomendasikan untuk: Pemulihan bencana
Cache Azure untuk Redis mendukung opsi untuk mengimpor dan mengekspor file Redis Database (RDB) untuk memberikan portabilitas data. Ini memungkinkan Anda mengimpor data ke Azure Cache for Redis atau mengekspor data dari Azure Cache for Redis dengan menggunakan snapshot RDB. Snapshot RDB dari cache premium diekspor ke blob di Akun Azure Storage. Anda dapat membuat skrip untuk memicu ekspor secara berkala ke akun penyimpanan Anda. Untuk informasi dan petunjuk selengkapnya, lihat Mengimpor dan Mengekspor data di Azure Cache for Redis.
Akun penyimpanan untuk ekspor
Pertimbangkan untuk memilih akun penyimpanan geo-redundan untuk memastikan ketersediaan data tinggi bagi data yang Anda ekspor. Untuk informasi lebih lanjut, lihat Redundansi Azure Storage.
Replikasi Geo Pasif
Tingkatan yang berlaku: Premium
Direkomendasikan untuk: Pemulihan bencana - satu wilayah
Geo-replikasi adalah mekanisme untuk menautkan dua atau lebih instans Azure Cache for Redis, biasanya mencakup dua wilayah Azure. Replikasi geografis dirancang terutama untuk pemulihan bencana lintas wilayah. Dua instans cache tingkat Premium terhubung melalui replikasi geografis dengan cara yang menyediakan baca dan tulis ke cache utama Anda, dan data tersebut direplikasi ke cache sekunder.
Untuk informasi selengkapnya tentang cara menyiapkannya, lihat Mengonfigurasi geo-replikasi untuk instans Premium Azure Cache for Redis.
Jika wilayah yang menghosting cache utama turun, Anda harus memulai failover dengan: pertama, membatalkan tautan cache sekunder, lalu, memperbarui aplikasi Anda untuk menunjuk ke cache sekunder untuk dibaca dan ditulis.
Replikasi Geo Aktif
Tingkatan yang berlaku: Enterprise, Enterprise Flash
Direkomendasikan untuk: Ketersediaan Tinggi, Pemulihan bencana - multi-wilayah
Tingkat Perusahaan mendukung bentuk replikasi geografis yang lebih canggih yang disebut replikasi geografis aktif yang menawarkan ketersediaan yang lebih tinggi dan pemulihan bencana lintas wilayah di beberapa wilayah. Perangkat lunak Azure Cache for Redis Enterprise menggunakan tipe data yang direplikasi bebas konflik untuk mendukung penulisan ke beberapa instans cache, menggabungkan perubahan, dan menyelesaikan konflik. Anda dapat menggabungkan hingga lima instans cache tingkat Enterprises di berbagai wilayah Azure untuk membentuk grup replikasi geografis.
Aplikasi yang menggunakan cache semacam itu dapat membaca dan menulis ke instans cache geo-distribusi melalui titik akhir yang sesuai. Aplikasi harus menggunakan apa yang paling dekat dengan setiap instans komputasi, memberi Anda latensi terendah. Untuk informasi selengkapnya, lihat Mengonfigurasi geo-replikasi aktif untuk instans Enterprise Azure Cache for Redis.
Jika wilayah salah satu cache di grup replikasi Anda berhenti beroperasi, aplikasi Anda perlu beralih ke wilayah lain yang tersedia.
Saat cache dalam grup replikasi Anda tidak tersedia, sebaiknya pantau penggunaan memori untuk cache lain dalam grup replikasi yang sama. Sementara salah satu cache sedang berhenti beroperasi, cache lain dalam grup replikasi mulai menyimpan metadata yang tidak dapat mereka bagikan dengan cache yang sedang berhenti beroperasi. Jika penggunaan memori untuk cache yang tersedia mulai tumbuh pada tingkat tinggi setelah salah satu cache turun, pertimbangkan untuk membatalkan tautan cache yang tidak tersedia dari grup replikasi.
Untuk informasi selengkapnya mengenai membatalkan tautan secara paksa, lihat Membatalkan Tautan Secara Paksa jika terjadi waktu henti wilayah.
Menghapus dan membuat ulang cache
Tingkatan yang berlaku: Standar, Premium, Enterprise, Enterprise Flash
Jika Anda mengalami pemadaman regional, pertimbangkan untuk membuat ulang cache Anda di wilayah yang berbeda, dan memperbarui aplikasi Anda untuk terhubung ke cache baru sebagai gantinya. Penting untuk dipahami bahwa data hilang selama pemadaman regional. Kode aplikasi Anda harus tahan terhadap kehilangan data.
Setelah wilayah yang terpengaruh dipulihkan, Azure Cache for Redis yang tidak tersedia akan dipulihkan secara otomatis, dan tersedia untuk digunakan lagi. Untuk strategi selengkapnya untuk memindahkan cache Anda ke wilayah lain, lihat Memindahkan instans Azure Cache for Redis ke wilayah yang berbeda.
Langkah berikutnya
Pelajari selengkapnya tentang cara mengonfigurasikan opsi ketersediaan tinggi Azure Cache for Redis.