Apa praktik terbaik untuk tingkat Enterprise dan Enterprise Flash

Berikut adalah praktik terbaik saat menggunakan tingkat Enterprise dan Enterprise Flash Azure Cache for Redis.

Redundansi zona

Kami sangat menyarankan Anda menyebarkan cache baru dalam konfigurasi zona redundan . Redundansi zona memastikan bahwa simpul Redis Enterprise tersebar di antara tiga zona ketersediaan, meningkatkan redundansi dari pemadaman tingkat pusat data. Menggunakan redundansi zona meningkatkan ketersediaan. Untuk informasi selengkapnya, lihat Perjanjian Tingkat Layanan (SLA) untuk Layanan Online.

Redundansi zona penting di tingkat Perusahaan karena instans cache Anda selalu menggunakan setidaknya tiga simpul. Dua simpul adalah simpul data, yang menyimpan data Anda, dan simpul kuorum. Peningkatan kapasitas menskalakan jumlah simpul data dalam kenaikan angka genap.

Ada juga node lain yang disebut node kuorum. Simpul ini memantau simpul data dan secara otomatis memilih simpul utama baru jika ada failover. Redundansi zona memastikan bahwa simpul didistribusikan secara merata di tiga zona ketersediaan, meminimalkan potensi kehilangan kuorum. Pelanggan tidak dikenakan biaya untuk node kuorum dan tidak ada biaya lain untuk menggunakan redundansi zona di luar biaya bandwidth intra-zonal.

Penskalaan

Di tingkat Enterprise dan Enterprise Flash dari Azure Cache for Redis, sebaiknya prioritaskan peningkatan skala daripada penskalaan. Prioritaskan peningkatan skala karena tingkat Enterprise dibangun di Redis Enterprise, yang mampu memanfaatkan lebih banyak inti CPU dalam VM yang lebih besar.

Sebaliknya, rekomendasi yang berlawanan berlaku untuk tingkat Dasar, Standar, dan Premium, yang dibangun di atas Redis sumber terbuka. Dalam tingkatan tersebut, memprioritaskan perluasan skala daripada peningkatan skala direkomendasikan dalam banyak kasus.

Pemanfaatan Sharding dan CPU

Di tingkat Dasar, Standar, dan Premium Azure Cache for Redis, menentukan jumlah CPU virtual (vCPU) yang digunakan sangat mudah. Setiap simpul Redis berjalan pada VM khusus. Proses server Redis berutas tunggal, menggunakan satu vCPU pada setiap simpul utama dan setiap replika. VCPU lain pada VM masih digunakan untuk aktivitas lain, seperti koordinasi alur kerja untuk tugas yang berbeda, pemantauan kesehatan, dan beban TLS, antara lain.

Saat Anda menggunakan pengklusteran, efeknya adalah menyebarkan data ke lebih banyak simpul dengan satu shard per simpul. Dengan meningkatkan jumlah pecahan, Anda secara linier meningkatkan jumlah vCPU yang Anda gunakan, berdasarkan jumlah pecahan dalam kluster.

Redis Enterprise, di sisi lain, dapat menggunakan beberapa vCPU untuk instans Redis itu sendiri. Dengan kata lain, semua tingkatan Azure Cache for Redis dapat menggunakan beberapa vCPU untuk tugas latar belakang dan pemantauan, tetapi hanya tingkat Enterprise dan Enterprise Flash yang dapat menggunakan beberapa vCPU per VM untuk shard Redis. Tabel menunjukkan jumlah vCPU efektif yang digunakan untuk setiap konfigurasi SKU dan kapasitas (yaitu, peluasan skala).

Tabel menunjukkan jumlah vCPU yang digunakan untuk pecahan utama, bukan pecahan replika. Pecahan tidak memetakan satu-ke-satu ke jumlah vCPU. Tabel hanya mengilustrasikan vCPU, bukan pecahan. Beberapa konfigurasi menggunakan lebih banyak pecahan daripada vCPU yang tersedia untuk meningkatkan performa dalam beberapa skenario penggunaan.

E5

Kapasitas vCPU yang efektif
2 1
4 2
6 6

E10

Kapasitas vCPU yang efektif
2 2
4 6
6 6
8 16
10 20

E20

Kapasitas vCPU yang efektif
2 2
4 6
6 6
8 16
10 20

E50

Kapasitas vCPU yang efektif
2 6
4 6
6 6
8 30
10 30

E100

Kapasitas vCPU yang efektif
2 6
4 30
6 30
8 30
10 30

E200

Kapasitas vCPU yang efektif
2 30
4 60
6 60
8 120
10 120

E400

Kapasitas vCPU yang efektif
2 60
4 120
6 120
8 240
10 240

F300

Kapasitas vCPU yang efektif
3 6
9 30

F700

Kapasitas vCPU yang efektif
3 30
9 30

F1500

Kapasitas vCPU yang efektif
3 30
9 90

Pengklusteran di Perusahaan

Tingkat Enterprise dan Enterprise Flash secara inheren terkluster, berbeda dengan tingkat Dasar, Standar, dan Premium. Implementasi tergantung pada kebijakan pengklusteran yang dipilih. Tingkat Perusahaan menawarkan dua pilihan untuk Kebijakan Pengklusteran: OSS dan Enterprise. Kebijakan kluster OSS direkomendasikan untuk sebagian besar aplikasi karena mendukung throughput maksimum yang lebih tinggi, tetapi ada kelebihan dan kekurangan untuk setiap versi.

Kebijakan pengklusteran OSS menerapkan REDIS Cluster API yang sama dengan Redis sumber terbuka. REDIS Cluster API memungkinkan klien Redis untuk terhubung langsung ke setiap simpul Redis, meminimalkan latensi dan mengoptimalkan throughput jaringan. Akibatnya, skalabilitas mendekati linier diperoleh saat meluaskan skala kluster dengan lebih banyak simpul. Kebijakan pengklusteran OSS umumnya memberikan latensi dan performa throughput terbaik, tetapi mengharuskan pustaka klien Anda untuk mendukung Pengklusteran Redis. Kebijakan pengklusteran OSS juga tidak dapat digunakan dengan modul RediSearch.

Kebijakan pengklusteran Enterprise adalah konfigurasi yang lebih sederhana yang menggunakan satu titik akhir untuk semua koneksi klien. Menggunakan kebijakan pengklusteran Enterprise merutekan semua permintaan ke satu simpul Redis yang kemudian digunakan sebagai proksi, merutekan permintaan secara internal ke simpul yang benar di kluster. Keuntungan dari pendekatan ini adalah bahwa pustaka klien Redis tidak perlu mendukung Pengklusteran Redis untuk memanfaatkan beberapa simpul. Kelemahannya adalah bahwa proksi simpul tunggal dapat menjadi hambatan, baik dalam pemanfaatan komputasi atau throughput jaringan. Kebijakan pengklusteran Enterprise adalah satu-satunya yang dapat digunakan dengan modul RediSearch.

Perintah multi-kunci

Karena tingkat Perusahaan menggunakan konfigurasi berkluster, Anda mungkin melihat CROSSSLOT pengecualian pada perintah yang beroperasi pada beberapa kunci. Perilaku bervariasi tergantung pada kebijakan pengklusteran yang digunakan. Jika Anda menggunakan kebijakan pengklusteran OSS, perintah multi-kunci mengharuskan semua kunci dipetakan ke slot hash yang sama.

Anda mungkin juga melihat CROSSSLOT kesalahan dengan kebijakan pengklusteran Perusahaan. Hanya perintah multi-kunci berikut yang diizinkan di seluruh slot dengan pengklusteran Enterprise: DEL, , MSET, MGETEXISTS, UNLINK, dan TOUCH.

Dalam database Active-Active, perintah tulis multi-kunci (DEL, , MSETUNLINK) hanya dapat dijalankan pada kunci yang berada di slot yang sama. Namun, perintah multi-kunci berikut diizinkan di seluruh slot dalam database Active-Active: MGET, EXISTS, dan TOUCH. Untuk informasi selengkapnya, lihat Pengklusteran database.

Menangani Skenario Penurunan Wilayah dengan Geo-Replication Aktif

Replikasi geografis aktif adalah fitur yang kuat untuk meningkatkan ketersediaan secara dramatis saat menggunakan tingkat perusahaan Azure Cache for Redis. Namun, Anda harus mengambil langkah-langkah untuk menyiapkan cache Anda jika ada pemadaman regional.

Misalnya, pertimbangkan tips berikut:

  • Identifikasi terlebih dahulu cache lain mana dalam grup replikasi geografis yang akan dialihkan jika suatu wilayah tidak berfungsi.
  • Pastikan firewall diatur sehingga aplikasi dan klien apa pun dapat mengakses cache cadangan yang diidentifikasi.
  • Setiap cache dalam grup replikasi geografis memiliki kunci aksesnya sendiri. Tentukan bagaimana aplikasi beralih ke kunci akses yang berbeda saat menargetkan cache cadangan.
  • Jika cache dalam grup replikasi geografis turun, penusunan metadata mulai terjadi di semua cache dalam grup replikasi geografis. Metadata tidak dapat dibuang sampai penulisan dapat disinkronkan lagi ke semua cache. Anda dapat mencegah build-up metadata dengan membatalkan tautan paksa cache yang tidak berfungsi. Pertimbangkan untuk memantau memori yang tersedia di cache dan membatalkan tautan jika ada tekanan memori, terutama untuk beban kerja tulis-berat.

Anda juga dapat menggunakan pola pemutus sirkuit. Gunakan pola untuk mengalihkan lalu lintas secara otomatis dari cache yang mengalami pemadaman wilayah, dan menuju cache cadangan dalam grup replikasi geografis yang sama. Gunakan layanan Azure seperti Azure Traffic Manager atau Azure Load Balancer untuk mengaktifkan pengalihan.

Persistensi Data vs Pencadangan Data

Fitur persistensi data di tingkat Enterprise dan Enterprise Flash dirancang untuk secara otomatis menyediakan titik pemulihan cepat untuk data saat cache tidak berfungsi. Pemulihan cepat dimungkinkan dengan menyimpan file RDB atau AOF dalam disk terkelola yang dipasang ke instans cache. File persistensi pada disk tidak dapat diakses oleh pengguna.

Banyak pelanggan ingin menggunakan persistensi untuk mengambil cadangan data secara berkala di cache mereka. Kami tidak menyarankan Agar Anda menggunakan persistensi data dengan cara ini. Sebagai gantinya, gunakan fitur impor/ekspor . Anda dapat mengekspor salinan data cache dalam format RDB langsung ke akun penyimpanan yang Anda pilih dan memicu ekspor data sesering yang Anda butuhkan. Ekspor dapat dipicu baik dari portal atau dengan menggunakan alat CLI, PowerShell, atau SDK.