Pertama, Sentinel bukan penyeimbang beban atau proxy untuk Redis.
Kedua, tidak semua kegagalan adalah kematian tuan rumah. Terkadang server hang sebentar, terkadang kabel jaringan terlepas, dll. Karena ini, menjalankan Sentinel pada host yang sama dengan instance Redis Anda bukanlah praktik yang baik. Jika Anda menggunakan Sentinel untuk mengelola failover, apa pun yang kurang dari tiga penjaga yang berjalan di node selain master dan slave Redis Anda akan menimbulkan masalah.
Sentinel menggunakan mekanisme kuorum untuk memilih failover dan slave. Dengan kurang dari dua penjaga, Anda berisiko mengalami perpecahan otak di mana dua atau lebih server Redis menganggap mereka master.
Bayangkan skenario di mana Anda menjalankan dua server dan menjalankan sentinel di masing-masing server. Jika Anda kehilangan satu, Anda kehilangan kemampuan failover yang andal.
Klien hanya terhubung ke Sentinel untuk mempelajari informasi koneksi master saat ini. Setiap kali klien kehilangan konektivitas, mereka mengulangi proses ini. Sentinel bukan proxy untuk Redis - perintah untuk Redis langsung masuk ke Redis.
Satu-satunya alasan yang dapat diandalkan untuk menjalankan Sentinel dengan kurang dari tiga penjaga adalah untuk penemuan layanan, yang berarti tidak menggunakannya untuk manajemen failover.
Pertimbangkan dua skenario host:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Jika Host B untuk sementara kehilangan konektivitas jaringan ke Host A dalam skenario ini, HostB akan mempromosikan dirinya menjadi master. Sekarang Anda memiliki:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Setiap klien yang terhubung ke Sentinel 2 akan diberi tahu bahwa Host B adalah masternya, sedangkan klien yang terhubung ke Sentinel 1 akan diberi tahu Host A sebagai master (yang, jika Anda memiliki Sentinel di belakang penyeimbang beban, berarti setengah dari klien Anda).
Jadi yang perlu Anda jalankan untuk mendapatkan manajemen failover andal minimum yang dapat diterima adalah:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Klien Anda terhubung ke penjaga dan mendapatkan master saat ini untuk instans Redis (berdasarkan nama), lalu hubungkan ke sana. Jika master mati, koneksi harus diputuskan oleh klien dan klien akan/harus terhubung ke Sentinel lagi dan mendapatkan informasi baru.
Seberapa baik setiap pustaka klien menangani ini bergantung pada pustaka.
Idealnya Host C, D, dan E berada di host yang sama tempat Anda terhubung ke Redis (mis. Host klien). atau mewakili sampel yang baik mendapatkannya. Dorongan utama di sini adalah untuk memastikan Anda memeriksa dari mana Anda perlu terhubung ke Redis. Gagal menempatkan mereka di DC/Rack/Wilayah yang sama dengan klien.
Jika Anda ingin klien Anda berbicara dengan penyeimbang beban, cobalah untuk menempatkan Sentinel Anda di node LB tersebut jika memungkinkan, tambahkan host non-LB tambahan seperlunya untuk mendapatkan jumlah penjaga yang ganjil> 2. Pengecualian untuk ini adalah jika Anda host klien bersifat dinamis karena jumlahnya tidak konsisten (mereka meningkatkan lalu lintas, turun untuk periode yang lambat, misalnya). Dalam skenario ini, Anda harus menjalankan Sentinel pada host non-klien dan non-redis-server.
Perhatikan bahwa jika Anda melakukan ini, Anda kemudian perlu menulis daemon yang memantau saluran Sentinel PUBSUB untuk acara sakelar master untuk memperbarui LB -yang harus Anda konfigurasikan untuk hanya berbicara dengan master saat ini (jangan pernah mencoba berbicara dengan keduanya). Lebih banyak pekerjaan untuk melakukan itu tetapi menggunakan Sentinel transparan untuk klien - yang hanya tahu untuk berbicara dengan LB IP/Port.
