Redis adalah sistem manajemen basis data kelas NoSQL (DBMS non-relasional) yang ditempatkan seluruhnya dalam RAM. Untuk mengakses data, model "kunci" - "nilai" digunakan. DBMS seperti itu sering digunakan untuk menyimpan cache dalam layanan yang skalabel, untuk menyimpan gambar dan data kecil.
Redis DBMS banyak digunakan karena:
- kecepatan tinggi, karena semua data disimpan dalam RAM;
- lintas platform;
- distribusi di bawah lisensi BSD (berlaku untuk perangkat lunak open source).
Luasnya distribusi dan penerapan Redis dapat diperkirakan dengan sejumlah besar dokumentasi dengan semua jenis kasus di
situs web resmi proyek .
Jika Anda menggunakan penskalaan horizontal layanan DirectumRX, Anda harus menggunakan instalasi Redis fail-safe untuk bekerja dengan benar dengan layanan penyimpanan DirectumRX dan layanan akses web DirectumRX.
Redis akan menyimpan data operasional, cache, dan informasi lain yang diperlukan untuk pengoperasian layanan dalam mode penskalaan sehingga proses interaksi pengguna dengan sistem tidak bergantung pada instalasi yang sedang digunakannya.
Redis tidak akan menyimpan data sensitif dan tidak akan berada di bawah beban berat. Tetapi jika terjadi kegagalan Redis, pengguna akan mengalami banyak kesalahan saat beralih antar instalasi.
Di situs web resmi Redis, ada 2 cara untuk memastikan penskalaan horizontal dan toleransi kesalahan:
- Menggunakan Redis Sentiel .
- Menggunakan Redis Cluster .
Pertimbangkan untuk menyesuaikan opsi ini.
Konfigurasikan Redis Sentiel
Opsi menggunakan Redis Sentiel (Redis Tracking Node) diimplementasikan dalam Redis 2.4 dan terdiri dalam menggunakan layanan Redis Sentiel tambahan untuk memantau ketersediaan wizard. Dia juga melakukan konfigurasi node replika jika terjadi kegagalan wizard. Menentukan node SLAVE mana yang akan menjadi MASTER dan melakukan konfigurasi ulang saat bepergian.
Menerapkan skema klasik:
Mungkin ada banyak node SLAVE (hingga 1000 menurut situs resmi), untuk pekerjaan produktif disarankan untuk menggunakan setidaknya dua node SLAVE.
Biasanya, skema dikonfigurasi sedemikian rupa sehingga layanan Redis Sentiel dikonfigurasi pada node MASTER dan SLAVE, dan jika simpul MASTER gagal, node pemantauan yang tersisa memutuskan untuk memperkenalkan MASTER baru.
Versi Redis saat ini tersedia untuk diunduh dari
situs web resmi pengembang produk . Namun, situs distribusi hanya tersedia untuk Linux. Pada suatu waktu,
proyek Microsoft untuk porting Redis ke Windows sedang berkembang, tetapi saat ini proyek menghentikan pengembangan pada versi 3.2.100, jadi dalam artikel ini kami akan mempertimbangkan opsi penyebaran yang paling relevan - di Linux.
Sebagai node uji, kita akan menggunakan dua host virtual redis1 dan redis2 dengan distribusi Linux yang diinstal dari Debian 10.
Pertama, perbarui daftar paket dari repositori default dan instal Redis:
apt-get update && apt-get upgrade apt install redis-server
Periksa versinya:
root@redis1:/home/user
Biarkan redis1 bertindak sebagai simpul MASTER dan redis2 bertindak sebagai simpul SLAVE.
Untuk melakukan ini, kami menulis dalam konfigurasi Redis file parameter yang diperlukan yang akan memungkinkan Anda untuk membuat replika (belum toleran terhadap kesalahan).
Untuk redis1 di file konfigurasi /etc/redis/redis.conf, tentukan:
Untuk redis2 di file konfigurasi /etc/redis/redis.conf, tentukan:
Mulai ulang layanan redis-server di kedua node:
root@redis1:/etc/redis
Kami memeriksa pada sisi MASTER bahwa node menjadi replika dan menerima peran yang diperlukan:
root@redis1:/etc/redis
Di sisi BUDAK, kami melihat situasi yang sama:
root@redis2:/etc/redis
Sekarang Anda perlu mengkonfigurasi replika sehingga secara otomatis dikembalikan jika salah satu node gagal. Untuk melakukan ini, kita memerlukan layanan pelacakan Redis Sentinel.
Berdasarkan
dokumentasi , layanan pemantauan Redis Sentinel dapat melakukan operasi berikut:
- Memeriksa ketersediaan node MASTER dan SLAVE dan dapat mengirim peringatan tentang tidak dapat diaksesnya node.
- Jika simpul MASTER gagal, simpul saksi dapat menempatkan simpul SLAVE dalam mode MASTER, serta mengkonfigurasi ulang simpul-simpul SLAVE yang tersisa, dan mereka mulai bekerja dengan MASTER yang baru.
- Membuat perubahan pada file konfigurasi dari MASTER dan SLAVE node.
Untuk kemurnian percobaan, kami akan menempatkan layanan saksi pada VM redis3 terpisah.
Kami menghubungkan repositori Redis dengan cara yang sama dan menginstal paket redis-sentinel:
apt install redis-sentinel
Setelah instalasi, Anda perlu membuat pengaturan dalam file konfigurasi dari node pemantauan /etc/redis/sentinel.conf:
Mulai ulang layanan setelah melakukan pengaturan:
root@redis3:/etc/redis
Pastikan layanan pelacakan melihat MASTER dan SLAVE:
root@redis3:/etc/redis
Kami memulai eksperimen.
Kami mensimulasikan kegagalan, menghentikan layanan redis-server pada redis1 node dan mendapatkan informasi terkini dari node saksi:
root@redis3:/etc/redis
Kami melihat MASTER telah berubah.
Kami akan mengembalikan operasi simpul redis1 dan memeriksa kondisinya:
root@redis3:/var/log/redis
Kita melihat bahwa simpul menerima peran SLAVE, dan simpul redis2 adalah simpul MASTER.
Mensimulasikan kegagalan simpul redis2 dan memeriksa status simpul saksi:
root@redis3:/var/log/redis
Dan status simpul redis1:
root@redis3:/var/log/redis
Hebat, mekanismenya bekerja. Tetapi sekarang muncul pertanyaan bagaimana kami akan menghubungkan layanan DirectumRX kami, karena mereka membutuhkan alamat node tunggal. Kami akan mengatasi situasi menggunakan layanan HAProxy.
Redis Node Proxying
Layanan proxy tcp dapat bertindak sebagai proxy terbalik untuk simpul Redis. Pada artikel ini, kami akan mempertimbangkan penggunaan HAProxy, karena ini adalah alat khusus yang dirancang untuk memberikan ketersediaan dan penyeimbangan muatan yang tinggi, dan digunakan oleh layanan online yang dikenal secara universal. Baca lebih lanjut tentang HAProxy
di halaman pengembang .
Instal HAProxy pada simpul redis3:
root@redis3:/var/log/redis
Dalam file konfigurasi HAProxy /etc/haproxy/haproxy.cfg, tambahkan pengaturan untuk permintaan proxy ke node Redis:
… frontend ft_redis bind *:6379 name redis mode tcp default_backend bk_redis backend bk_redis mode tcp option tcp-check tcp-check connect
Dalam konfigurasi ini, diindikasikan bahwa kami akan mem-proxy setiap permintaan yang datang ke semua antarmuka mesin virtual saat ini di alamat pada port 6379. Kami akan mentransfer permintaan ke node yang akan menjawab bahwa ia memiliki peran MASTER.
Mulai ulang layanan haproxy:
root@redis3:/etc/haproxy
Mari kita coba sambung menggunakan klien redis-cli dan buat kunci uji:
root@redis3:/etc/haproxy
Hentikan redis1 node dan kueri lagi daftar kunci:
127.0.0.1:6379> info keyspace Error: Server closed the connection (3.01s) 127.0.0.1:6379> info keyspace
Kita melihat bahwa untuk beberapa waktu koneksi terputus, tetapi kemudian koneksi dipulihkan kembali dan semua data tetap di tempatnya.
Sekarang cukup untuk mendaftarkan alamat proxy terbalik di file konfigurasi layanan DirectumRX untuk terhubung ke Redis.
Konfigurasikan Redis Cluster
Opsi pengelompokan Redis Cluster, diimplementasikan untuk versi redis 3.0 dan lebih tinggi, adalah solusi untuk membuat dan mengelola sebuah cluster dengan segmentasi dan replikasi data. Melakukan tugas-tugas manajemen simpul, replikasi, sinkronisasi data pada node dan memastikan akses aplikasi klien ke simpul MASTER dalam hal kegagalan salah satu dari beberapa simpul MASTER.
Redis Cluster bekerja dalam mode multimaster, setiap node MASTER dapat memiliki satu atau lebih node SLAVE (hingga 1000).
Penskalaan adalah fungsi utama gugus. Selain itu, cluster dapat menjamin toleransi kesalahan dari layanan Redis:
- jika beberapa node tidak berfungsi, cluster mendistribusikan kembali beban dari mereka ke node lain;
- jika node kunci tidak berfungsi, maka seluruh cluster berakhir.
Situasi mungkin muncul ketika Klien 2 menulis ke simpul M2. M2 menjawab "OK" dan mencoba menulis ke S2. Pada saat yang sama, M2 tidak menunggu penyelesaian pertukaran data yang benar dengan S2, tetapi segera menanggapi klien. Dalam hal ini, replika S2 mungkin tidak memiliki semua data. Oleh karena itu, disarankan untuk menggunakan beberapa replika SLAVE.
Situasi juga dapat muncul ketika M1, M3 berhenti untuk "melihat" M2, dan klien masih terus menulis data ke M2. Jika ketidaktersediaan akan berlanjut untuk beberapa waktu (parameter cluster-node-timeout), maka dalam hal ini S2 akan dimasukkan ke mode MASTER, dan M2 akan berhenti bekerja sendiri.
Dokumentasi resmi merekomendasikan menggunakan 6 node - satu instance Redis per node, yang memungkinkan keandalan yang lebih besar, tetapi tidak ada yang melarang menggunakan tiga node dengan topologi koneksi berikut:
Jika salah satu node fisik gagal, replika SLAVE yang sesuai akan masuk ke mode MASTER, dan operasi tidak akan terganggu.
Kami menerapkan 3 mesin virtual (redis1, redis2 dan redis3) di bangku tes, yang masing-masing akan menjalankan 2 instance Redis.
Aplikasi klien akan terhubung ke port tertentu yang ditentukan dalam file konfigurasi klien, oleh karena itu, pasangan MASTER - SLAVE harus bekerja pada port yang sama.
Untuk pasangan M1 - S1 kita akan menggunakan port 6381
Untuk pasangan M2 - S2 kita akan menggunakan port 6382
Untuk pasangan M3 - S3 kita akan menggunakan port 6383
Siapkan file konfigurasi
Di redis1:
cp /etc/redis/redis.conf /etc/redis/m1_redis.conf cp /etc/redis/redis.conf /etc/redis/s2_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Di redis2:
cp /etc/redis/redis.conf /etc/redis/m2_redis.conf cp /etc/redis/redis.conf /etc/redis/s3_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Pada redis3:
cp /etc/redis/redis.conf /etc/redis/m3_redis.conf cp /etc/redis/redis.conf /etc/redis/s1_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Isi file konfigurasi sesuai dengan templat:
bind <IP- > protected-mode no
Mari kita meluncurkan node Redis:
Node redis1:
root@redis1:/etc/redis
Redis2 simpul:
root@redis2:/etc/redis
Redis3 simpul:
root@redis3:/etc/redis
Untuk mengkonfigurasi cluster, Anda perlu menggunakan utilitas klien redis-cli, memberikannya daftar ip: port pasang server yang akan memainkan peran MASTER dan SLAVE:
redis-cli --cluster create redis1-ip:6381 redis2-ip:6382 redis3-ip:6383 redis1-ip:6382 redis2-ip:6383 redis3-ip:6381 --cluster-replicas 1
, di mana opsi --cluster-replicas 1 memberi tahu Anda berapa banyak SLAVE yang akan dimiliki masing-masing master, dan mereka secara otomatis dipilih dari daftar replika yang ditransfer.
root@redis1:~/redis/src
Cluster dibangun dengan benar. Kami akan menampilkan informasi tentang klaster:
root@redis1:~/redis/src
Untuk menguji replika tertentu, seperti Redis Sentiel, Anda dapat menggunakan perintah replikasi INFO:
root@redis1:~/redis/src
Mari kita coba membuat beberapa kunci dan memverifikasi bahwa kunci-kunci ini muncul di replika:
192.168.9.51:6381> SET key1 test1 -> Redirected to slot [9189] located at 192.168.9.52:6382 OK 192.168.9.52:6382> SET key2 test2 -> Redirected to slot [4998] located at 192.168.9.51:6381 OK 192.168.9.51:6381> SET key3 test3 OK 192.168.9.51:6381>
Periksa M2:
root@redis2:/home/user
Dan di M3:
root@redis3:/home/user
Kami akan menonaktifkan redis1 node dan memeriksa cara kerja S1:
192.168.9.52:6382> CLUSTER NODES <b>182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave,fail d499af3672b3063c7239572ec311ad3160f280ae 1569509904727 1569509900000 4 connected</b> 485ffb786e9763955e6f10ffc59247690ad9bc11 <i>192.168.9.53:6381@16381 master</i> - 0 1569510017272 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569510018274 5 connected <b>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 master,fail - 1569509906731 1569509901721 1 connected</b> 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569510019275 3 connected 10923-16383 d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 myself,master - 0 1569510017000 2 connected 5461-10922
Kami melihat informasi tentang kegagalan M1 dan S2 dan S3 telah beralih ke mode MASTER.
Periksa di mana kunci disimpan:
192.168.9.52:6382> GET key1 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6381> GET key3 "test3" 192.168.9.53:6381>
Kunci yang sebelumnya disimpan di redis1 sekarang tersedia di redis3.
Kembalikan operasi simpul redis1 dan periksa keadaan simpul M1 dan S2:
192.168.9.53:6381> CLUSTER NODES <i>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 slave 485ffb786e9763955e6f10ffc59247690ad9bc11 0 1569511658217 7 connected 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave d499af3672b3063c7239572ec311ad3160f280ae 0 1569511657000 4 connected</i> d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 master - 0 1569511656000 2 connected 5461-10922 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569511656000 3 connected 10923-16383 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381@16381 myself,master - 0 1569511656000 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569511657216 5 connected
Kesehatan M1 dan S2 telah pulih, tetapi sekarang M1 dalam mode SLAVE.
Dan kuncinya juga pada simpul redis3:
192.168.9.53:6383> GET key1 -> Redirected to slot [9189] located at 192.168.9.52:6382 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6383> GET key3 -> Redirected to slot [935] located at 192.168.9.53:6381 "test3"
Cluster dikonfigurasi dan pemulihan Redis diuji.
Untuk mengakses layanan DirectumRX, Anda juga perlu mengonfigurasi proksi terbalik, seperti dalam hal mengatur Redis Sentiel.
Alih-alih sebuah kesimpulan
Artikel ini tidak mempertimbangkan cara lain untuk meningkatkan toleransi kesalahan Redis - menggunakan manajer sumber daya gugus pihak ketiga, misalnya
Pacemaker . Dalam hal ini, akan dimungkinkan untuk bertahan dengan dua node, namun, ada kemungkinan besar kehilangan data jika terjadi keadaan darurat.
Untuk proksi terbalik (dalam hal ini, HAProxy), juga diinginkan untuk memberikan toleransi kesalahan, tetapi masalah ini juga di luar cakupan artikel ini. Jika Anda tertarik dengan topik ini, opsi penyebaran ini juga dapat dipertimbangkan dalam artikel terpisah dengan penyetelan langkah-demi-langkah dan menguji hasilnya.
Anda dapat menemukan tautan di bawah ini untuk mengetahui lebih lanjut tentang topik ini:
Redis cluster tutorialDokumentasi Redis SentinelManual Konfigurasi HAProxy .