Sentinel dan Cluster

Sentinel adalah proses pengawas yang mengelola ketersediaan (high availability, HA) satu grup replikasi, sedangkan Cluster adalah mode Redis yang membagi data ke banyak master melalui sharding. Topik ini membahas tugas Sentinel, penyiapan satu grup berisi master, replika, dan Sentinel pada port 6392 sampai 6394, failover terpandu yang dapat diamati langsung, serta cara Cluster membagi data melalui hash slot. Bagian Cluster dibahas secara konseptual karena pembentukannya menuntut enam proses server, sedangkan seluruh percobaan Sentinel dijalankan pada lab terisolasi yang nyata.

Tugas Sentinel pada ketersediaan#

Satu master dengan satu replika masih menyisakan pekerjaan manual pada saat master gagal. Topik replikasi memperlihatkan promosi dengan REPLICAOF NO ONE, tetapi keputusan kapan promosi dilakukan tetap dipegang manusia. Sentinel mengambil alih keputusan itu melalui tiga pekerjaan, yaitu mengawasi master dan replika dengan PING berkala, menandai master sebagai turun apabila tidak menjawab dalam down-after-milliseconds, lalu mempromosikan salah satu replika menjadi master tanpa campur tangan. Klien yang mengikuti pola Sentinel tidak lagi menyimpan alamat master, melainkan bertanya kepada Sentinel setiap memerlukan alamat, sehingga pergantian master tidak mengubah kode aplikasi.

Keputusan turunnya master lazimnya disepakati lebih dari satu Sentinel karena Sentinel juga dapat mati. Angka kuorum (quorum) pada konfigurasi menyatakan jumlah Sentinel yang harus setuju sebelum master dinyatakan turun, dan penyebaran yang disarankan berupa tiga Sentinel pada tiga mesin berbeda dengan kuorum dua. Lab pada topik ini sengaja menjalankan satu Sentinel agar sederhana, dan demonstrasi failover menggunakan perintah eksplisit dari administrator sehingga tidak menunggu kesepakatan kuorum. Diagram berikut merangkum posisi Sentinel di antara master, replika, dan klien.

Menyiapkan master, replika, dan Sentinel#

Lab ini menyalakan tiga proses dari satu direktori /tmp/lab-sentinel, yaitu master di port 6392, replika di port 6393, dan Sentinel di port 6394. Konfigurasi Sentinel ditulis ke berkas sentinel.conf yang memuat empat baris penting, yaitu port Sentinel, nama grup yang diawasi beserta alamat master dan kuorum, ambang waktu master dianggap turun, dan batas waktu seluruh tahap failover. Nama grup kuis menjadi penanda yang digunakan klien dan perintah administratif untuk menunjuk grup ini. Jalankan blok berikut untuk menyalakan ketiganya.

# hentikan sisa proses lab dari topik sebelumnya, bila ada
redis-cli -p 6390 shutdown nosave 2>/dev/null || true
redis-cli -p 6391 shutdown nosave 2>/dev/null || true
redis-cli -p 6392 shutdown nosave 2>/dev/null || true
redis-cli -p 6393 shutdown nosave 2>/dev/null || true
redis-cli -p 6394 shutdown nosave 2>/dev/null || true
# siapkan direktori lab sentinel
mkdir -p /tmp/lab-sentinel
# tulis konfigurasi sentinel: awasi master bernama kuis di port 6392
cat > /tmp/lab-sentinel/sentinel.conf <<'CONF'
port 6394
logfile "/tmp/lab-sentinel/sentinel.log"
sentinel monitor kuis 127.0.0.1 6392 2
sentinel down-after-milliseconds kuis 800
sentinel failover-timeout kuis 3000
CONF
# nyalakan master di port 6392
redis-server --port 6392 --bind 127.0.0.1 --daemonize yes --dir /tmp/lab-sentinel --save "" --protected-mode no --repl-diskless-sync-delay 0 --logfile /tmp/lab-sentinel-master.log
# nyalakan replika di port 6393 dan sambungkan ke master
redis-server --port 6393 --bind 127.0.0.1 --daemonize yes --dir /tmp/lab-sentinel --save "" --protected-mode no --logfile /tmp/lab-sentinel-replica.log
redis-cli -p 6393 REPLICAOF 127.0.0.1 6392
# nyalakan Sentinel sebagai proses terpisah
redis-server /tmp/lab-sentinel/sentinel.conf --sentinel --daemonize yes
# tunggu ketiga proses siap, lalu pastikan koneksinya hidup
sleep 1
redis-cli -p 6392 PING
redis-cli -p 6393 PING
redis-cli -p 6394 PING

OK
PONG
PONG
PONG

Nilai down-after-milliseconds 800 sengaja dipilih kecil agar demonstrasi berlangsung cepat, sedangkan nilai produksi lazim berkisar puluhan detik agar gangguan jaringan sesaat tidak langsung memicu failover. Perintah sentinel get-master-addr-by-name kuis berikut menjawab pertanyaan yang selalu diajukan klien pengikut Sentinel, yaitu alamat master grup kuis saat ini.

# tanyakan alamat master grup kuis kepada Sentinel
redis-cli -p 6394 sentinel get-master-addr-by-name kuis

127.0.0.1
6392

Keluaran berisi dua baris, yaitu alamat dan port master yang sedang dipercaya Sentinel. Apabila master berganti, jawaban atas nama grup yang sama berubah, sedangkan klien tidak perlu tahu lebih dari itu.

Failover terpandu#

Perintah SENTINEL FAILOVER kuis memerintahkan Sentinel mempromosikan replika tanpa menunggu master benar-benar mati, sehingga seluruh tahapan failover dapat diamati dari terminal. Replika dipromosikan menjadi master dalam waktu sekitar satu detik, sedangkan konversi master lama menjadi replika mengikuti siklus periodik Sentinel dan selesai dalam belasan detik. Blok berikut menjalankan failover, lalu menunggu dengan perulangan terbatas sampai Sentinel mencatat alamat master yang baru, sehingga keluarannya menunjukkan keadaan setelah promosi tuntas.

# perintahkan Sentinel menjalankan failover atas grup kuis
redis-cli -p 6394 sentinel failover kuis
# tunggu Sentinel mencatat master baru, periksa jawabannya tiap setengah detik
for i in $(seq 1 20); do
  MASTER=$(redis-cli -p 6394 sentinel get-master-addr-by-name kuis | tail -1)
  [ "$MASTER" = "6393" ] && break
  sleep 0.5
done
# periksa peran replika yang dipromosikan pada port 6393
redis-cli -p 6393 role | head -1

OK
master

Peran port 6393 sudah menjadi master, sedangkan master lama pada port 6392 untuk sesaat masih mempertahankan peran lamanya karena konversinya menunggu siklus periodik Sentinel. Blok berikut menunggu dengan perulangan terbatas sampai master lama benar-benar turun menjadi replika, sehingga keluarannya selalu menunjukkan keadaan setelah konversi tuntas.

# tunggu master lama dikonversi menjadi replika, periksa perannya tiap setengah detik
for i in $(seq 1 26); do
  PERAN=$(redis-cli -p 6392 role | head -1)
  [ "$PERAN" = "slave" ] && break
  sleep 0.5
done
# periksa peran baru master lama pada port 6392
redis-cli -p 6392 role | head -1

slave

Peran kedua server bertukar, yaitu port 6392 yang semula master kini menjadi slave dan port 6393 menjadi master. Tanyakan kembali alamat master kepada Sentinel dengan nama grup yang sama untuk melihat sisi klien dari peristiwa ini.

# tanyakan lagi alamat master kepada Sentinel setelah failover
redis-cli -p 6394 sentinel get-master-addr-by-name kuis

127.0.0.1
6393

Jawaban Sentinel berpindah dari port 6392 ke port 6393 tanpa perubahan apa pun pada nama grup, dan inilah mekanisme yang membuat klien pengikut Sentinel selalu menemukan master terbaru. Sentinel juga menulis setiap tahap ke berkas lognya, mulai dari +try-failover, +promoted-slave, sampai +switch-master, sehingga kejadian yang baru saja terjadi dapat ditelusuri kembali dari /tmp/lab-sentinel/sentinel.log.

Cluster untuk sharding#

Sentinel menyelesaikan ketersediaan, tetapi kapasitas data tetap terbatas pada satu master, karena seluruh dataset hidup di satu proses. Redis Cluster memecah keterbatasan itu dengan membagi keyspace ke dalam 16384 hash slot, yaitu potongan keyspace yang masing-masing dimiliki satu master. Setiap key dipetakan ke slot melalui perhitungan CRC16 atas nama key, lalu hasilnya diambil modulo 16384, sehingga CLUSTER KEYSLOT kuis:soal-1 misalnya selalu menghasilkan slot yang sama untuk key yang sama. Klien yang mengirim perintah ke node yang salah mendapat alihan MOVED berisi alamat node pemilik slot, lalu klien yang mengikuti protokol cluster mengulang permintaannya ke sana.

Pemilihan antara Sentinel dan Cluster mengikuti kebutuhan skala. Sentinel dipilih apabila data muat pada satu server dan yang dibutuhkan hanyalah ketersediaan, sedangkan Cluster dipilih apabila data atau beban tulis melampaui kapasitas satu server. Cluster sudah menyertakan ketersediaan karena setiap master boleh memiliki replikanya, sehingga failover slot terjadi tanpa Sentinel. Konsekuensinya, Cluster menuntut disiplin baru pada aplikasi, misalnya operasi multi-key hanya aman apabila seluruh key yang terlibat jatuh pada slot yang sama, yang dicapai melalui hash tag berbentuk kurung kurawal pada nama key. Blok berikut memperlihatkan bentuk perintah pembentukan cluster enam node, yaitu tiga master dan tiga replika, dan hanya berfungsi apabila keenam proses server tersebut memang berjalan.

# tidak-dijalankan
# contoh pembentukan cluster: butuh enam proses server di port 7000 sampai 7005
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1

Percobaan topik ini selesai, sehingga Sentinel beserta kedua server dimatikan tanpa menyimpan data ke disk.

# matikan Sentinel beserta kedua server tanpa menyimpan data ke disk
redis-cli -p 6394 shutdown nosave
redis-cli -p 6393 shutdown nosave
redis-cli -p 6392 shutdown nosave

Ringkasan#

• Sentinel mengawasi master dan replika dengan PING, menyatakan master turun setelah down-after-milliseconds, lalu mempromosikan replika menjadi master secara otomatis dengan kesepakatan kuorum.
• Klien pengikut Sentinel bertanya alamat master melalui sentinel get-master-addr-by-name, sehingga pergantian master setelah failover tidak mengubah kode aplikasi.
• SENTINEL FAILOVER menjalankan failover terpandu tanpa menunggu master mati, dengan pertukaran peran yang selesai dalam belasan detik pada lab ini.
• Cluster membagi 16384 hash slot ke banyak master dan menyertakan failover per master, dipilih ketika data tidak lagi muat pada satu server, sedangkan Sentinel dipilih untuk ketersediaan pada kapasitas satu server.

Referensi#

• Sentinel — Redis — Dokumentasi resmi Sentinel yang menjelaskan kuorum, down-after-milliseconds, dan tahapan failover.
• Scaling with Redis Cluster — Redis — Tutorial resmi cluster yang menjelaskan hash slot, alihan MOVED, dan pembentukan cluster.
• CLUSTER KEYSLOT — Redis — Dokumentasi perintah penghitung slot sebuah key sebagai bukti pemetaan CRC16.