Mitigasi Kegagalan - Amazon ElastiCache (Redis OSS)

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mitigasi Kegagalan

Saat merencanakan ElastiCache implementasi Amazon Anda, Anda harus merencanakan sehingga kegagalan memiliki dampak minimal pada aplikasi dan data Anda. Topik pada bagian ini membahas pendekatan yang dapat Anda ambil untuk melindungi aplikasi dan data Anda dari kegagalan.

Mengurangi Kegagalan saat Menjalankan Redis OSS

Saat menjalankan mesin Redis OSS, Anda memiliki opsi berikut untuk meminimalkan dampak kegagalan node atau Availability Zone.

Mitigasi Kegagalan Simpul

Cache nirserver secara otomatis memitigasi kegagalan simpul dengan arsitektur Multi-AZ sehingga kegagalan simpul terlihat jelas untuk aplikasi Anda. Klaster yang dirancang sendiri harus dikonfigurasi dengan tepat untuk mengurangi kegagalan simpul individual.

Untuk mengurangi dampak kegagalan node Redis OSS pada cluster yang dirancang sendiri, Anda memiliki opsi berikut:

Mengurangi Kegagalan: Grup Replikasi Redis OSS

Grup replikasi Redis OSS terdiri dari satu node utama yang aplikasi Anda dapat membaca dari dan menulis ke, dan dari 1 hingga 5 node replika read-only. Setiap kali data ditulis ke simpul primer, data ini juga diperbarui secara asinkron ke simpul replika baca.

Saat salah satu replika baca gagal
  1. ElastiCache mendeteksi replika baca yang gagal.

  2. ElastiCache mengambil node yang gagal off line.

  3. ElastiCache meluncurkan dan menyediakan node pengganti di AZ yang sama.

  4. Simpul baru melakukan sinkronisasi dengan simpul primer.

Selama proses ini, aplikasi Anda dapat terus melakukan pembacaan dan penulisan menggunakan simpul lain.

Redis OSS Multi-AZ

Anda dapat mengaktifkan Multi-AZ pada grup replikasi Redis OSS Anda. Terlepas dari apakah Anda memiliki Multi-AZ yang aktif atau tidak, primer yang gagal akan terdeteksi dan diganti secara otomatis. Namun prosesnya akan berbeda tergantung apakah Multi-AZ aktif atau tidak.

Jika Multi-AZ aktif
  1. ElastiCache mendeteksi kegagalan node primer.

  2. ElastiCache mempromosikan simpul replika baca dengan lag replikasi paling sedikit ke simpul utama.

  3. Replika lain melakukan sinkronisasi dengan simpul primer yang baru.

  4. ElastiCache memutar replika baca di AZ primer yang gagal.

  5. Simpul baru disinkronkan dengan primer yang baru dipromosikan.

Melakukan failover ke simpul replika umumnya lebih cepat daripada membuat dan menyediakan simpul primer baru. Ini berarti aplikasi Anda dapat melanjutkan kembali proses penulisan ke simpul primer Anda lebih cepat daripada ketika Multi-AZ tidak diaktifkan.

Untuk informasi selengkapnya, lihat Meminimalkan downtime di ElastiCache (Redis OSS) dengan Multi-AZ.

Jika Multi-AZ tidak aktif
  1. ElastiCache mendeteksi kegagalan primer.

  2. ElastiCache mengambil offline utama.

  3. ElastiCache membuat dan menyediakan simpul utama baru untuk menggantikan primer yang gagal.

  4. ElastiCache menyinkronkan primer baru dengan salah satu replika yang ada.

  5. Setelah sinkronisasi selesai, simpul baru berfungsi sebagai simpul primer klaster.

Selama langkah 1 sampai 4 proses ini, aplikasi Anda tidak dapat menulis ke simpul primer. Namun, aplikasi Anda dapat terus membaca dari simpul replika Anda.

Untuk perlindungan tambahan, sebaiknya Anda meluncurkan simpul pada grup replikasi Anda di Zona Ketersediaan (AZ) yang berbeda. Jika Anda melakukan ini, kegagalan AZ hanya akan berdampak pada simpul di AZ tersebut dan bukan yang lain.

Untuk informasi selengkapnya, lihat Ketersediaan tinggi menggunakan grup replikasi.

Mitigasi Kegagalan Zona Ketersediaan

Cache nirserver secara otomatis memitigasi kegagalan simpul dengan arsitektur Multi-AZ yang direplikasi sehingga kegagalan AZ terlihat jelas untuk aplikasi Anda.

Untuk mengurangi dampak kegagalan Zona Ketersediaan di klaster yang dirancang sendiri, tempatkan simpul untuk setiap serpihan di sebanyak mungkin Zona Ketersediaan.

Sebanyak apa pun simpul yang Anda miliki di sebuah serpihan, jika semua simpul terletak di Zona Ketersediaan yang sama, kegagalan fatal pada AZ tersebut akan membuat semua data serpihan Anda hilang. Namun, jika Anda menempatkan simpul Anda di beberapa AZ, maka kegagalan dari satu AZ hanya mengakibatkan kehilangan simpul di AZ tersebut.

Setiap kali kehilangan simpul, Anda dapat mengalami penurunan performa karena operasi baca menjadi terbagi ke simpul yang lebih sedikit. Penurunan performa ini akan berlanjut hingga simpul tersebut diganti.

Untuk informasi tentang menentukan Availability Zones untuk Redis OSS node, lihat. Membuat cluster Redis OSS (mode cluster dinonaktifkan) (Konsol)

Untuk informasi selengkapnya tentang wilayah dan Zona Ketersediaan, lihat Memilih wilayah dan zona ketersediaan.

Rekomendasi

Sebaiknya buat cache nirserver, bukan klaster yang dirancang sendiri, karena Anda secara otomatis mendapatkan toleransi kesalahan yang lebih baik tanpa konfigurasi tambahan. Saat membuat klaster yang dirancang sendiri, ada dua jenis kegagalan yang perlu direncanakan: kegagalan simpul individual dan kegagalan Zona Ketersediaan yang luas. Rencana mitigasi kegagalan terbaik akan mengatasi kedua jenis kegagalan tersebut.

Meminimalkan Dampak Kegagalan Simpul

Untuk meminimalkan dampak dari kegagalan simpul, sebaiknya implementasi Anda menggunakan beberapa simpul di setiap serpihan dan mendistribusikan simpul di beberapa Zona Ketersediaan. Ini dilakukan secara otomatis untuk cache nirserver.

Untuk cluster yang dirancang sendiri, kami menyarankan Anda mengaktifkan Multi-AZ pada grup replikasi Anda sehingga secara otomatis ElastiCache akan gagal ke replika jika node utama gagal.

Meminimalkan Dampak Kegagalan Zona Ketersediaan

Untuk meminimalkan dampak kegagalan Zona Ketersediaan, sebaiknya Anda meluncurkan simpul Anda di sebanyak mungkin Zona Ketersediaan yang tersedia. Menyebarkan simpul Anda secara merata di seluruh AZ akan meminimalkan dampak jika terjadi kegagalan AZ. Ini dilakukan secara otomatis untuk cache nirserver.

Tindakan pencegahan lain

Jika Anda menjalankan Redis OSS, maka selain di atas, kami sarankan Anda menjadwalkan backup reguler cluster Anda. Cadangan (snapshot) membuat file .rdb yang dapat Anda gunakan untuk memulihkan cache Anda jika terjadi kegagalan atau kerusakan. Untuk informasi selengkapnya, lihat Melakukan snapshot dan pemulihan.