Redis sentinel vs pengelompokan

Saya memahami redis sentinel adalah cara untuk mengonfigurasi HA (ketersediaan tinggi) di antara beberapa contoh redis. Seperti yang saya lihat, ada satu contoh redis yang secara aktif melayani permintaan klien pada waktu tertentu. Ada dua server tambahan yang standby (menunggu kegagalan terjadi, jadi salah satunya bisa beraksi kembali).

• Apakah ini pemborosan sumber daya?
• Apakah ada cara yang lebih baik untuk menggunakan sepenuhnya sumber daya yang tersedia?
• Apakah pengelompokan Redis merupakan alternatif dari Redis sentinel?

Saya sudah mencari dokumentasi redis untuk sentinel dan pengelompokan , dapatkah seseorang yang memiliki pengalaman menjelaskan.

MEMPERBARUI

BAIK. Dalam skenario penerapan saya yang sebenarnya, saya memiliki dua server yang didedikasikan untuk redis. Saya memiliki server lain, server Jboss saya sedang berjalan. Aplikasi yang berjalan di Jboss dikonfigurasi untuk terhubung ke server master redis (M).

Skenario failover

Idealnya, saya pikir ketika server cache Master gagal (baik proses Redis turun atau kegagalan mesin) aplikasi di Jboss perlu terhubung ke server cache Slave. Bagaimana cara mengonfigurasi server redis untuk mencapai ini?

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1

Pertama, mari bicara sentinel.

Sentinel mengelola failover, tidak mengkonfigurasi Redis untuk HA. Ini adalah perbedaan penting. Kedua, diagram yang Anda posting sebenarnya adalah pengaturan yang buruk - Anda tidak ingin menjalankan Sentinel pada node yang sama dengan node Redis yang dikelola. Ketika Anda kehilangan tuan rumah itu, Anda kehilangan keduanya.

Mengenai "Apakah itu pemborosan sumber daya?" itu tergantung pada kasus penggunaan Anda. Anda tidak memerlukan tiga node Redis dalam penyiapan itu, Anda hanya perlu dua. Tiga meningkatkan redundansi Anda, tetapi tidak diperlukan. Jika Anda membutuhkan redundansi tambahan maka itu bukan pemborosan sumber daya. Jika Anda tidak memerlukan redundansi, Anda cukup menjalankan satu instance Redis dan menyebutnya baik - karena menjalankan lebih banyak akan "sia-sia".

Alasan lain untuk menjalankan dua budak adalah untuk membagi bacaan. Sekali lagi, jika Anda membutuhkannya maka itu tidak akan sia-sia.

Mengenai "Apakah ada cara yang lebih baik untuk menggunakan sepenuhnya sumber daya yang tersedia?" kami tidak dapat menjawabnya karena terlalu bergantung pada skenario dan kode spesifik Anda. Artinya, jika jumlah data yang akan disimpan "kecil" dan kecepatan perintah tidak terlalu tinggi, ingatlah bahwa Anda tidak perlu mendedikasikan sebuah host untuk Redis.

Sekarang untuk "Apakah pengelompokan Redis merupakan alternatif untuk Redis sentinel?". Itu benar-benar tergantung sepenuhnya pada kasus penggunaan Anda. Redis Cluster bukanlah solusi HA - ini adalah solusi multiple writer / lebih besar dari ram. Jika tujuan Anda hanya HA maka kemungkinan besar tidak akan cocok untuk Anda. Redis Cluster hadir dengan batasan, terutama di sekitar operasi multi-kunci, jadi ini belum tentu merupakan operasi "cukup gunakan cluster" langsung.

Jika menurut Anda memiliki tiga host yang menjalankan Redis (dan tiga menjalankan sentinel) adalah pemborosan, Anda kemungkinan besar akan menganggap Cluster lebih seperti itu karena memang membutuhkan lebih banyak sumber daya.

Pertanyaan yang Anda ajukan mungkin terlalu luas dan berbasis opini untuk bertahan seperti yang tertulis. Jika Anda memiliki kasus / masalah tertentu yang sedang Anda tangani, harap perbarui agar kami dapat memberikan bantuan dan informasi khusus.

Pembaruan untuk spesifik:

Untuk manajemen failover yang tepat dalam skenario Anda, saya akan menggunakan 3 sentinel, satu yang berjalan di server JBoss Anda. Jika Anda memiliki 3 node JBoss, lanjutkan dengan satu di masing-masing. Saya akan memiliki pod Redis (master + slave) di node terpisah, dan membiarkan sentinel mengelola failover.

Dari sana, tinggal wiring JBoss / Jedis menggunakan Sentinel untuk informasi dan manajemen koneksi. Karena saya tidak menggunakannya, pencarian cepat ternyata Jedis memiliki dukungan untuk itu, Anda hanya perlu mengkonfigurasinya dengan benar. Beberapa contoh yang saya temukan ada di Mencari contoh Jedi dengan Sentinel dan https://github.com/xetorthio/jedis/issues/725 yang berbicara tentang JedisSentinelPoolmenjadi rute untuk menggunakan kolam.

Ketika Sentinel menjalankan failover, klien akan diputuskan dan Jedis akan (harus?) Menangani koneksi ulang dengan menanyakan Sentinel siapa master saat ini.

Rekomendasi, di mana-mana, adalah memulai dengan jumlah kejadian ganjil, tidak menggunakan dua atau kelipatan dua. Itu telah diperbaiki, tapi mari kita perbaiki beberapa poin lainnya

Pertama, mengatakan bahwa Sentinel menyediakan failover tanpa HA adalah salah. Ketika Anda mengalami failover, Anda memiliki HA dengan manfaat tambahan dari status aplikasi yang direplikasi. Perbedaannya adalah Anda dapat memiliki HA dalam sistem tanpa replikasi (ini HA tetapi tidak toleran terhadap kesalahan).

Kedua, menjalankan sentinel pada mesin yang sama dengan target redis instance bukanlah "penyiapan yang buruk": jika Anda kehilangan sentinel, atau instance redis Anda, atau seluruh mesin, hasilnya sama. Mungkin itulah sebabnya setiap contoh konfigurasi seperti itu menunjukkan keduanya berjalan di mesin yang sama.

Ini bukan jawaban langsung untuk pertanyaan Anda, tetapi pikirkan, ini informasi berguna untuk pemula Redis, seperti saya. Juga pertanyaan ini muncul sebagai link pertama di google saat mencari "Redis cluster vs sentinel".

Redis Sentinel adalah nama dari solusi ketersediaan tinggi Redis ... Ini tidak ada hubungannya dengan Kluster Redis dan dimaksudkan untuk digunakan oleh orang-orang yang tidak membutuhkan Kluster Redis, tetapi hanya cara untuk melakukan pengalihan otomatis saat master Misalnya tidak berfungsi dengan benar.

Diambil dari draf desain Redis Sentinel 1.3

Ini bukan obviuos ketika Anda baru mengenal Redis dan menerapkan solusi failover. Dokumentasi resmi tentang sentinel dan pengelompokan tidak bisa dibandingkan satu sama lain, jadi sulit untuk memilih cara yang benar tanpa membaca banyak dokumentasi.

Ini adalah pemahaman saya setelah membenturkan kepala saya sepanjang dokumentasi.

Sentinel adalah sejenis solusi siaga panas di mana budak terus direplikasi dan siap untuk dipromosikan kapan saja. Namun, ini tidak akan mendukung penulisan multi-node apa pun. Budak dapat dikonfigurasi untuk operasi baca. TIDAK benar bahwa Sentinel tidak akan menyediakan HA, ia memiliki semua fitur cluster aktif-pasif yang khas (meskipun itu bukan istilah yang tepat untuk digunakan di sini).

Kluster Redis kurang lebih merupakan solusi terdistribusi, bekerja di atas pecahan. Setiap potongan data didistribusikan di antara node master dan slave. Faktor replikasi minimal 2 memastikan bahwa Anda memiliki dua shard aktif yang tersedia di seluruh master dan slave. Jika Anda mengetahui sharding di Mongo atau Elasticsearch, itu akan mudah menyusul.

Redis dapat beroperasi dalam cluster terpartisi (dengan banyak master dan budak dari master tersebut) atau mode instans tunggal (master tunggal dengan budak replika).
The Link di sini mengatakan:

Saat menggunakan Redis dalam mode instans tunggal, di mana satu server Redis mengelola seluruh database yang tidak dipartisi, Redis Sentinel digunakan untuk mengelola ketersediaannya

Ia juga mengatakan:

Kluster Redis, tempat data dipartisi di antara beberapa instance utama, mengelola ketersediaan dengan sendirinya dan tidak memerlukan komponen tambahan.

Jadi HA dapat dipastikan dalam 2 skenario yang disebutkan. Semoga ini menghilangkan keraguan. Cluster Redis dan sentinel bukanlah alternatif satu sama lain. Mereka hanya digunakan untuk memastikan HA dalam kasus berbeda dari master yang dipartisi atau tidak.

Redis Sentinel melakukan failover yang mempromosikan replika saat mereka melihat master sedang down. Anda biasanya menginginkan jumlah node sentinel yang ganjil. Untuk contoh satu master dan satu replika, harus digunakan 3 sentinel agar dapat terjadi konsensus dalam pengambilan keputusan. Idealnya sentinel ke-3 ada di server ke-3 agar keputusan tidak miring (tergantung kegagalan). Sentinel menangani perubahan pengaturan konfigurasi master / replika pada node Anda sehingga promosi dan sinkronisasi terjadi dalam urutan yang benar dan Anda tidak menimpa data dengan membawa master lama yang gagal yang sekarang berisi data yang lebih lama.

Setelah Anda menyiapkan node sentinel untuk melakukan failover, Anda perlu memastikan bahwa Anda mengarah ke instance yang benar. Lihat contoh konfigurasi HAProxy untuk ini . HAProxy melakukan pemeriksaan kesehatan dan akan menunjuk ke master baru jika terjadi kegagalan.

Pengelompokan akan memungkinkan Anda menskalakan secara horizontal dan dapat membantu menangani beban tinggi. Diperlukan sedikit kerja untuk menyiapkan dan mengkonfigurasi di depan.

Ada cabang open source Redis, "KeyDB" yang telah menghilangkan kebutuhan akan node sentinel dengan opsi replika aktif. Ini memungkinkan node replika menerima baca dan tulis. Ketika terjadi kegagalan, HAProxy menghentikan pembacaan / penulisan dengan node yang gagal dan hanya menggunakan node aktif yang tersisa yang sudah disinkronkan. Timestamping memungkinkan node yang gagal untuk bergabung kembali secara otomatis dan menyinkronkan ulang tanpa kehilangan data saat mereka kembali online. Penyiapannya sederhana dan untuk lalu lintas yang lebih tinggi, Anda tidak memerlukan penyiapan dimuka khusus untuk mengarahkan pembacaan ke node replika dan baca / tulis ke master. Lihat contoh replikasi aktif di sini . KeyDB juga multi-utas yang untuk beberapa aplikasi mungkin menjadi alternatif untuk pengelompokan, tetapi sangat tergantung pada apa yang Anda butuhkan.

Ada juga contoh pengaturan clustering secara manual dan dengan alat create-cluster . Ini adalah langkah yang sama jika Anda menggunakan Redis (ganti 'keydb' dengan 'redis' dalam instruksi)

Info tambahan untuk jawaban di atas

Kluster Redis

• Salah satu tujuan utama cluster Redis adalah mendistribusikan beban data Anda secara merata / seragam dengan sharding

• Redis Cluster tidak menggunakan hashing yang konsisten, tetapi bentuk sharding yang berbeda di mana setiap kunci secara konseptual merupakan bagian dari apa yang disebut sebagai slot hash

• Ada 16384 slot hash di Redis Cluster, Setiap node di Redis Cluster bertanggung jawab atas subset dari slot hash, jadi, misalnya, Anda mungkin memiliki cluster dengan 3 node, di mana:

  Node A berisi slot hash dari 0 hingga 5500, Node B berisi slot hash dari 5501 hingga 11000, Node C berisi slot hash dari 11001 hingga 16383

Ini memungkinkan kami untuk menambah dan menghapus node di cluster dengan mudah. Misalnya jika kita ingin menambahkan node D baru, kita perlu memindahkan beberapa slot hash dari node A, B, C ke D

• Cluster Redis mendukung struktur master-slave, Anda dapat membuat slave A1, B1, C2 bersama dengan master A, B, C saat membuat cluster, jadi saat master B turun, slave B1 dipromosikan sebagai master

Anda tidak memerlukan penanganan failover tambahan saat menggunakan Redis Cluster dan Anda sebaiknya tidak mengarahkan instance Sentinel ke node Cluster mana pun.

Jadi secara praktis, apa yang Anda dapatkan dengan Redis Cluster?

1. Kemampuan untuk secara otomatis membagi dataset Anda di antara beberapa node.

2. Kemampuan untuk melanjutkan operasi ketika bagian dari node mengalami kegagalan atau tidak dapat berkomunikasi dengan seluruh cluster.

Redis Sentinel

• Redis mendukung banyak budak yang mereplikasi data dari node master.
• Ini menyediakan cadangan untuk data di node master.
• Redis Sentinel adalah sistem yang dirancang untuk mengelola master dan slave. Ini berjalan sebagai program terpisah. Jumlah minimum sentinel yang dibutuhkan dalam sistem yang ideal adalah 3. Mereka berkomunikasi di antara mereka sendiri dan memastikan bahwa Master masih hidup, jika tidak hidup mereka akan mempromosikan salah satu budak sebagai master, jadi nanti ketika node mati berputar, itu akan menjadi bertindak sebagai budak majikan baru
• Kuorum dapat dikonfigurasi. Pada dasarnya itu adalah jumlah penjaga yang harus disetujui karena master sedang down. N / 2 +1 harus setuju. N adalah jumlah node dalam Pod (perhatikan setup ini disebut pod dan bukan cluster)

Jadi secara praktis, apa yang Anda dapatkan dengan Redis Sentinel?

Ini akan memastikan bahwa Guru selalu tersedia (jika tuan turun, budak akan dipromosikan sebagai tuan)

Referensi:

https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/

https://redis.io/topics/cluster-tutorial