Bagikan melalui

Kegagalan dan penambalan untuk Azure Cache for Redis

  • Artikel

Untuk membangun aplikasi klien yang tangguh dan sukses, sangat penting untuk memahami kegagalan di layanan Azure Cache for Redis. Kegagalan bisa menjadi bagian dari operasi manajemen yang direncanakan, atau mungkin disebabkan oleh kegagalan perangkat keras atau jaringan yang tidak direncanakan. Penggunaan umum kegagalan tembolokan terjadi ketika layanan manajemen menambal biner Azure Cache for Redis.

Dalam artikel ini, Anda akan menemukan informasi berikut:

  • Apa itu kegagalan?
  • Bagaimana kegagalan terjadi selama penambalan.
  • Cara untuk membangun aplikasi klien yang tangguh.

Apa itu kegagalan?

Mari kita mulai dengan gambaran umum kegagalan untuk Azure Cache for Redis.

Ringkasan singkat arsitektur tembolokan

Cache tersusun dari beberapa mesin virtual dengan alamat IP privat yang terpisah. Setiap mesin virtual, yang juga disebut sebagai simpul, tersambung ke penyeimbang beban bersama dengan satu alamat IP virtual. Setiap simpul menjalankan proses server Redis dan dapat diakses dengan menggunakan nama host dan port Redis. Setiap simpul dianggap sebagai simpul primer atau replika. Ketika aplikasi klien tersambung ke tembolokan, lalu lintasnya melewati penyeimbang beban ini dan secara otomatis dirutekan ke simpul utama.

Dalam tembolokan Dasar, simpul tunggal selalu merupakan primer. Dalam tembolokan Standar atau Premium, ada dua simpul: satu dipilih sebagai primer dan yang lainnya adalah replika. Karena tembolokan Standar dan Premium memiliki beberapa simpul, satu simpul mungkin tidak tersedia sementara yang lain terus memroses permintaan. Tembolokan terkluster terdiri dari banyak pecahan, masing-masing dengan simpul primer dan replika yang berbeda. Satu pecahan mungkin tidak berfungsi sementara yang lain tetap tersedia.

Catatan

Tembolokan Dasar tidak memiliki beberapa simpul dan tidak menawarkan perjanjian tingkat layanan (SLA) untuk ketersediaannya. Tembolokan Dasar direkomendasikan hanya untuk tujuan pengembangan dan pengujian. Gunakan tembolokan Standar atau Premium untuk penyebaran multi-simpul, untuk meningkatkan ketersediaan.

Penjelasan tentang kegagalan

Kegagalan terjadi ketika simpul replika mempromosikan dirinya untuk menjadi simpul utama, dan simpul primer yang lama menutup koneksi yang ada. Setelah simpul utama muncul kembali, simpul tersebut melihat adanya perubahan peran dan menurunkan dirinya untuk menjadi replika. Kemudian, simpul ini menyambungkan ke primer baru dan menyinkronkan data. Kegagalan bisa direncanakan atau tidak direncanakan.

Kegagalan yang direncanakan terjadi dalam dua waktu yang berbeda:

  • Pembaruan sistem, misalnya penambalan Redis atau peningkatan OS.
  • Operasi manajemen, misalnya penskalaan dan reboot.

Karena simpul-simpul menerima pemberitahuan sebelumnya tentang pembaruan, mereka dapat secara kooperatif bertukar peran dan dengan cepat memperbarui penyeimbang beban sehubungan dengan perubahan tersebut. Kegagalan yang direncanakan biasanya selesai dalam waktu kurang dari 1 detik.

Kegagalan yang tidak direncanakan bisa terjadi karena kegagalan perangkat keras, kegagalan jaringan, atau pemadaman tak terduga lainnya pada simpul utama. Node replika mempromosikan dirinya sendiri ke primer, tetapi prosesnya memakan waktu lebih lama. Sebuah simpul replika harus terlebih dahulu mendeteksi bahwa simpul utamanya tidak tersedia sebelum dapat memulai proses kegagalan. Simpul replika juga harus memverifikasi bahwa kegagalan yang tidak direncanakan ini tidak bersifat sementara atau lokal, untuk menghindari kegagalan yang tidak diperlukan. Penundaan dalam deteksi ini berarti bahwa kegagalan yang tidak direncanakan biasanya selesai dalam 10 hingga 15 detik.

Bagaimana penambalan terjadi?

Layanan Azure Cache for Redis secara rutin melakukan pemeliharaan untuk memperbarui tembolokan Anda menggunakan fitur dan perbaikan platform terbaru. Untuk menambal tembolokan, layanan mengikuti langkah-langkah berikut:

  1. Layanan ini menambal simpul replika terlebih dahulu.
  2. Replika yang di-patch secara kooperatif mempromosikan dirinya menjadi primer. Promosi ini dianggap sebagai kegagalan yang direncanakan.
  3. Node utama sebelumnya melakukan boot ulang untuk mengambil perubahan baru dan muncul kembali sebagai simpul replika.
  4. Simpul replika tersambung ke simpul utama dan menyinkronkan data.
  5. Ketika sinkronisasi data selesai, proses penambalan diulang untuk simpul yang tersisa.

Karena penambalan adalah kegagalan yang direncanakan, simpul replika dengan cepat mempromosikan dirinya untuk menjadi primer. Kemudian, simpul mulai melayani permintaan dan koneksi baru. Tembolokan Dasar tidak memiliki simpul replika dan tidak tersedia sampai pembaruan selesai. Setiap pecahan cache berkluster di-patch secara terpisah dan tidak menutup koneksi ke shard lain.

Penting

Simpul ditambal satu per satu untuk mencegah hilangnya data. Tembolokan Dasar akan mengalami kehilangan data. Tembolokan terkluster ditambal pecahan demi pecahan.

Beberapa tembolokan dalam grup dan wilayah sumber daya yang sama juga ditambal satu per satu. Tembolokan yang berada dalam grup sumber daya yang berbeda atau wilayah yang berbeda mungkin ditambal secara bersamaan.

Karena sinkronisasi data lengkap terjadi sebelum proses berulang, kehilangan data tidak mungkin terjadi ketika Anda menggunakan tembolokan Standar atau Premium. Anda dapat mencegah hilangnya data dengan mengekspor data dan mengaktifkan persistensi.

Beban tembolokan tambahan

Setiap kali kegagalan terjadi, tembolokan Standar dan Premium perlu mereplikasi data dari satu simpul ke simpul lainnya. Replikasi ini menyebabkan sejumlah peningkatan beban pada memori server dan CPU. Jika instans tembolokan sudah sangat berbeban, aplikasi klien mungkin mengalami peningkatan latensi. Dalam kasus ekstrem, aplikasi klien mungkin menerima pengecualian waktu habis. Untuk membantu mengurangi efek beban yang lebih berat, konfigurasikan pengaturan maxmemory-reserved tembolokan.

Bagaimana failover memengaruhi aplikasi klien saya?

Aplikasi klien dapat menerima beberapa kesalahan dari Azure Cache For Redis mereka. Jumlah kesalahan yang dilihat oleh aplikasi klien tergantung seberapa banyak operasi yang tertunda pada koneksi tersebut saat kegagalan terjadi. Setiap koneksi yang dirutekan melalui simpul yang menutup koneksinya melihat kesalahan.

Banyak pustaka klien dapat melaporkan berbagai jenis kesalahan saat koneksi putus, termasuk:

  • Pengecualian waktu habis
  • Pengecualian koneksi
  • Pengecualian soket

Jumlah dan jenis pengecualian tergantung letak permintaan pada jalur kode saat cache menutup koneksinya. Misalnya, operasi yang mengirimkan permintaan tetapi belum menerima respons ketika kegagalan terjadi mungkin mendapatkan pengecualian waktu habis. Permintaan baru pada objek koneksi tertutup akan menerima pengecualian koneksi hingga koneksi ulang berhasil tersambung.

Sebagian besar pustaka klien berusaha terkoneksi ulang ke tembolokan jika dikonfigurasi untuk melakukannya. Namun, bug yang tidak terduga kadang-kadang dapat menempatkan objek pustaka ke dalam kondisi yang tidak dapat dipulihkan. Jika kesalahan bertahan lebih lama dari durasi waktu yang telah dikonfigurasi sebelumnya, objek koneksi harus dibuat ulang. Dalam Microsoft.NET dan bahasa berorientasi objek lainnya, menciptakan koneksi kembali tanpa memulai ulang aplikasi dapat dilakukan dengan menggunakan pola ForceReconnect.

Dapatkah saya diberi tahu sebelum pemeliharaan?

Azure Cache for Redis menerbitkan pemberitahuan pemeliharaan runtime pada saluran terbitkan/berlangganan (pub/sub) yang disebut AzureRedisEvents. Banyak pustaka klien Redis populer mendukung saluran pub/sub. Menerima pemberitahuan dari saluran AzureRedisEvents biasanya merupakan tambahan sederhana untuk aplikasi klien Anda. Untuk informasi selengkapnya tentang peristiwa pemeliharaan, lihat AzureRedisEvents.

Catatan

Saluran AzureRedisEvents bukan mekanisme yang dapat memberi tahu Anda beberapa hari atau beberapa jam sebelumnya. Saluran dapat memberi tahu klien tentang peristiwa pemeliharaan server mendatang yang mungkin memengaruhi ketersediaan server. AzureRedisEvents hanya tersedia untuk tingkat Dasar, Standar, dan Premium.

Apa saja pembaruan yang disertakan dalam pemeliharaan?

Pemeliharaan mencakup pembaruan ini:

  • Pembaruan Redis Server: Setiap pembaruan atau patch biner server Redis.
  • Pembaruan komputer virtual (VM): Pembaruan apa pun dari komputer virtual yang menghosting layanan Redis. Pembaruan VM termasuk patching komponen perangkat lunak di lingkungan hosting untuk meningkatkan komponen jaringan atau menonaktifkan.

Apakah pemeliharaan muncul dalam kesehatan layanan di portal Azure sebelum patch?

Tidak, pemeliharaan tidak muncul di mana pun di bawah kesehatan layanan di portal atau tempat lain.

Berapa banyak waktu yang dapat saya dapatkan pemberitahuan sebelum pemeliharaan terencana?

Saat menggunakan AzureRedisEvents saluran, Anda diberi tahu 15 menit sebelum pemeliharaan.

Perubahan konfigurasi-jaringan klien

Perubahan konfigurasi jaringan sisi klien tertentu dapat memicu Tidak ada kesalahan koneksi yang tersedia . Perubahan tersebut bisa mencakup:

  • Menukar alamat IP virtual aplikasi klien antara slot penahapan dan slot produksi.
  • Menskalakan ukuran atau jumlah instans aplikasi Anda.

Perubahan tersebut dapat menyebabkan masalah konektivitas yang biasanya berlangsung kurang dari satu menit. Aplikasi klien Anda mungkin kehilangan koneksinya ke sumber daya jaringan eksternal lainnya, tetapi juga ke layanan Azure Cache for Redis.

Membangun ketahanan

Anda tidak dapat menghindari failover sepenuhnya. Sebagai gantinya, tulis aplikasi klien Anda agar tahan terhadap jeda koneksi dan permintaan yang gagal. Sebagian besar pustaka klien secara otomatis tersambung kembali ke titik akhir cache, tetapi hanya beberapa yang berusaha mencoba lagi permintaan yang gagal. Tergantung skenario aplikasi, mungkin masuk akal untuk menggunakan logika coba lagi dengan backoff.

Bagaimana cara menjadikan aplikasi saya tangguh?

Lihat pola desain ini untuk membangun klien yang tangguh, terutama pemutus sirkuit dan pola percobaan ulang:

Untuk menguji ketahanan aplikasi klien, gunakan reboot sebagai pemicu manual untuk koneksi putus.

Selain itu, kami sarankan Anda menggunakan pembaruan terjadwal untuk memilih saluran pembaruan dan jendela pemeliharaan untuk cache Anda untuk menerapkan patch runtime Redis selama jendela mingguan tertentu. Jendela ini biasanya merupakan periode ketika lalu lintas aplikasi klien sedang rendah, untuk menghindari kemungkinan terjadinya insiden. Untuk informasi selengkapnya, lihat Memperbarui saluran dan Menjadwalkan pembaruan.

Untuk informasi selengkapnya, lihat Ketahanan koneksi.

Konten terkait