Ketersediaan tinggi dan replika

Halaman ini menjelaskan cara arsitektur Memorystore for Redis Cluster mendukung dan menyediakan ketersediaan tinggi (HA). Halaman ini juga menjelaskan konfigurasi yang direkomendasikan yang berkontribusi pada peningkatan performa dan stabilitas instance.

Untuk mengetahui informasi selengkapnya tentang pertimbangan khusus wilayah, lihat Geografi dan wilayah.

Ketersediaan tinggi

Memorystore for Redis Cluster dibangun di atas arsitektur yang sangat tersedia, tempat klien Anda langsung mengakses VM Memorystore for Redis Cluster terkelola. Klien Anda melakukannya dengan terhubung ke alamat jaringan shard individual, seperti yang dijelaskan dalam Menghubungkan ke instance Memorystore for Redis Cluster.

Menghubungkan langsung ke shard memberikan manfaat berikut:

  • Koneksi langsung menghindari titik tunggal kegagalan karena setiap shard dirancang agar gagal secara independen. Misalnya, jika traffic dari beberapa klien membebani slot (chunk keyspace), kegagalan shard membatasi dampak pada shard yang bertanggung jawab untuk melayani slot.

  • Koneksi langsung menghindari hop perantara, yang meminimalkan waktu pulang pergi (latensi klien) antara klien dan VM Redis.

Sebaiknya buat instance multi-zona yang sangat tersedia, bukan instance zona tunggal karena keandalan yang lebih baik yang mereka berikan. Namun, jika Anda memilih untuk menyediakan instance tanpa replika, sebaiknya pilih instance zona tunggal. Untuk mengetahui informasi selengkapnya, lihat Memilih instance zona tunggal jika instance Anda tidak menggunakan replika.

Untuk mengaktifkan ketersediaan tinggi bagi instance Anda, Anda harus menyediakan minimal 1 node replika untuk setiap shard. Anda dapat melakukannya saat Membuat instance, atau Anda dapat Menskalakan jumlah replika menjadi setidaknya 1 replika per shard. Replika menyediakan Failover otomatis selama pemeliharaan terencana dan kegagalan shard yang tidak terduga.

Anda harus mengonfigurasi klien sesuai dengan panduan dalam Praktik terbaik klien Redis. Dengan menggunakan praktik terbaik yang direkomendasikan, klien Redis OSS Anda dapat menangani perubahan peran (failover otomatis) dan penetapan slot (penggantian node, penskalaan keluar/masuk konsumen) secara otomatis dan lancar untuk cluster Anda tanpa periode nonaktif.

Replika

Instance Memorystore for Redis Cluster yang sangat tersedia adalah resource regional. Artinya, VM primer dan replika shard didistribusikan di beberapa zona untuk melindungi dari pemadaman layanan zona. Memorystore for Redis Cluster mendukung instance dengan 0, 1, atau 2 replika per node.

Anda dapat menggunakan replika untuk meningkatkan throughput baca dengan menskalakan operasi baca. Untuk melakukannya, Anda harus menggunakan perintah READONLY untuk membuat koneksi yang memungkinkan klien Anda membaca dari replika. Untuk mengetahui detail selengkapnya tentang membaca dari replika, lihat Menskalakan dengan Redis Cluster.

Bentuk cluster dengan 0 replika per node

Instance Memorystore Cluster for Redis tanpa replika yang memiliki node yang dibagi secara merata di tiga zona.

Bentuk cluster dengan 1 replika per node

Instance Memorystore Cluster for Redis dengan satu replika per node, dan node dibagi secara merata di tiga zona.

Bentuk cluster dengan 2 replika per node

Instance Memorystore Cluster for Redis dengan dua replika per node, dan node dibagi secara merata di tiga zona.

Failover otomatis

Pengalihan otomatis dalam shard dapat terjadi karena pemeliharaan atau kegagalan tak terduga pada node utama. Selama failover, replika dipromosikan menjadi yang utama. Anda dapat mengonfigurasi replika secara eksplisit. Layanan ini juga dapat menyediakan replika tambahan untuk sementara selama pemeliharaan internal untuk menghindari periode nonaktif.

Pengalihan otomatis mencegah kehilangan data selama update pemeliharaan. Untuk mengetahui detail tentang perilaku failover otomatis selama pemeliharaan, lihat Perilaku failover otomatis selama pemeliharaan.

Durasi failover dan perbaikan node

Pengalihan otomatis dapat memerlukan waktu hingga puluhan detik untuk peristiwa yang tidak direncanakan seperti crash proses node utama, atau kegagalan hardware. Selama waktu ini, sistem mendeteksi kegagalan, dan memilih replika untuk menjadi replika utama yang baru.

Perbaikan node dapat memerlukan waktu beberapa menit agar layanan dapat mengganti node yang gagal. Hal ini berlaku untuk semua node utama dan replika. Untuk instance yang tidak memiliki ketersediaan tinggi (tidak ada replika yang disediakan), memperbaiki node utama yang gagal juga memerlukan waktu beberapa menit.

Perilaku klien selama failover yang tidak direncanakan

Koneksi klien kemungkinan akan direset, bergantung pada sifat kegagalan. Setelah pemulihan otomatis, koneksi harus dicoba lagi dengan backoff eksponensial untuk menghindari kelebihan beban pada node utama dan replika.

Klien yang menggunakan replika untuk throughput baca harus siap menghadapi penurunan kapasitas sementara hingga node yang gagal diganti secara otomatis.

Operasi tulis yang hilang

Selama failover yang disebabkan oleh kegagalan yang tidak terduga, penulisan yang dikonfirmasi dapat hilang karena sifat asinkron dari protokol replikasi Redis.

Aplikasi klien dapat memanfaatkan perintah WAIT Redis untuk meningkatkan keamanan data di dunia nyata. Ini adalah pendekatan upaya terbaik yang memiliki kekurangan seperti yang dijelaskan dalam dokumentasi perintah WAIT Redis.

Dampak keyspace dari pemadaman layanan satu zona

Bagian ini menjelaskan dampak pemadaman layanan satu zona pada instance Memorystore for Redis Cluster.

Instance multi-zona

  • Instance HA: Jika zona mengalami pemadaman layanan, seluruh keyspace tersedia untuk operasi baca dan tulis, tetapi karena beberapa replika baca tidak tersedia, kapasitas baca akan berkurang. Sebaiknya sediakan kapasitas cluster secara berlebih agar instance memiliki kapasitas baca yang cukup, jika terjadi pemadaman layanan satu zona yang jarang terjadi. Setelah pemadaman layanan berakhir, replika di zona yang terpengaruh akan dipulihkan dan kapasitas baca cluster akan kembali ke nilai yang dikonfigurasi. Untuk mengetahui informasi selengkapnya, lihat Pola untuk aplikasi yang skalabel dan andal.

  • Instance non-HA (tanpa replika): Jika terjadi pemadaman layanan di zona, bagian keyspace yang disediakan di zona yang terpengaruh akan mengalami penghapusan data, dan tidak tersedia untuk operasi tulis atau baca selama pemadaman layanan. Setelah pemadaman layanan berakhir, server utama di zona yang terpengaruh akan dipulihkan dan kapasitas cluster akan kembali ke nilai yang dikonfigurasi.

Instance zona tunggal

  • Instance HA dan Non-HA: Jika zona tempat instance disediakan mengalami pemadaman layanan, cluster tidak tersedia dan data akan dihapus. Jika zona lain mengalami pemadaman, cluster akan terus melayani permintaan baca dan tulis. Setelah pemadaman layanan berakhir, kapasitas cluster yang dikonfigurasi akan dipulihkan.

Praktik terbaik

Bagian ini menjelaskan praktik terbaik untuk ketersediaan tinggi dan replika.

Menambahkan replika

Menambahkan replika memerlukan snapshot RDB. Snapshot RDB menggunakan fork proses dan mekanisme'copy-on-write' untuk mengambil snapshot data node. Bergantung pada pola penulisan ke node, memori yang digunakan oleh node akan bertambah saat halaman yang disentuh oleh penulisan disalin. Penggunaan memori dapat mencapai dua kali ukuran data di node.

Untuk memastikan node memiliki memori yang cukup untuk menyelesaikan snapshot, pertahankan atau tetapkan maxmemory pada 80% dari kapasitas node sehingga 20% dicadangkan untuk overhead. Overhead memori ini, selain snapshot pemantauan, membantu Anda mengelola workload agar memiliki snapshot yang berhasil. Selain itu, saat menambahkan replika, kurangi traffic tulis sebanyak mungkin. Untuk mengetahui informasi selengkapnya, lihat Memantau cluster yang memiliki beban penulisan tinggi.