Analisis contoh kelompok Redis-Redis-php.cn

1. Mengapa K8s

1. Untuk meningkatkan penggunaan sumber dan menjimatkan kos, kelompok Redis berbilang barisan perniagaan digabungkan. Oleh kerana tiada pengasingan sumber CPU, ia sering berlaku bahawa penggunaan CPU nod Redis adalah terlalu tinggi, menyebabkan nod kelompok Redis lain bersaing untuk sumber CPU, menyebabkan kelewatan kegelisahan. Oleh kerana kluster berbeza bercampur, jenis masalah ini sukar dikesan dengan cepat dan menjejaskan kecekapan operasi dan penyelenggaraan. Penggunaan kontena K8 boleh menentukan permintaan CPU dan had CPU, yang meningkatkan penggunaan sumber sambil mengelakkan perbalahan sumber.

2. Pengerahan automatik

Proses penggunaan Redis Cluster pada mesin fizikal sangat menyusahkan Anda perlu menyemak pangkalan data meta-maklumat untuk mencari mesin dengan percuma sumber, dan membuat banyak pengubahsuaian manual Fail konfigurasi kemudiannya digunakan nod demi nod, dan akhirnya alat redis_trib digunakan untuk mencipta gugusan Permulaan gugusan baru selalunya mengambil masa satu atau dua jam.

K8s menggunakan kluster Redis melalui StatefulSet dan menggunakan peta konfigurasi untuk mengurus fail konfigurasi Ia hanya mengambil masa beberapa minit untuk menggunakan kluster baharu, yang meningkatkan kecekapan operasi dan penyelenggaraan.

2. Bagaimana K8s

Pelanggan mengakses secara seragam melalui VIP LVS dan memajukan permintaan perkhidmatan kepada kelompok Redis Cluster melalui Redis Proxy. Di sini kami memperkenalkan Redis Proxy untuk memajukan permintaan.

Analisis contoh kelompok Redis 1. Kaedah penggunaan Kluster Redis

Redis digunakan sebagai StatefulSet Sebagai perkhidmatan stateful, adalah paling munasabah untuk dipilih StatefulSet. Tetapkan RDB/AOF nod ke storan teragih. Apabila nod dimulakan semula dan hanyut ke mesin lain, RDB/AOF asal boleh diperolehi melalui PVC yang dipasang (PersistentVolumeClaim) untuk menyegerakkan data.

Perkhidmatan Ceph block ialah PV simpanan berterusan (PersistentVolume) yang kami pilih. Prestasi baca dan tulis Ceph lebih teruk daripada cakera keras tempatan, yang akan meningkatkan kelewatan baca dan tulis sebanyak 100 hingga 200 milisaat. Kependaman baca dan tulis storan teragih tidak menjejaskan perkhidmatan kerana penulisan RDB/AOF Redis adalah tak segerak.

Analisis contoh kelompok Redis 2. Pemilihan proksi

Terdapat banyak sumber terbuka Proksi Redis sumber terbuka adalah seperti berikut:

Kami berharap dapat terus menggunakan Kluster Redis untuk mengurus kluster Redis, jadi Codis dan Twemproxy tidak lagi dipertimbangkan. redis-cluster-proxy ialah Proksi yang dilancarkan secara rasmi oleh Redis dalam versi 6.0 yang menyokong protokol Redis Cluster Walau bagaimanapun, pada masa ini tiada versi yang stabil dan ia tidak boleh digunakan pada skala besar buat masa ini.

Satu-satunya alternatif ialah Cerberus dan Predixy. Berikut ialah keputusan ujian prestasi Cerberus dan Predixy dalam persekitaran K8s:

Persekitaran ujian

Alat ujian: penanda aras redis

CPU Proksi : 2 teras

CPU Pelanggan: 2 teras

Kluster Redis: 3 nod induk, 1 CPU setiap nod

Keputusan ujian

Analisis contoh kelompok Redis

Predixy mampu mencapai QPS yang lebih tinggi di bawah beban kerja dan konfigurasi yang sama, dan kependamannya juga agak hampir dengan Cerberus. Secara keseluruhan, Predixy mempunyai prestasi 33% hingga 60% lebih tinggi daripada Cerberus, dan lebih besar kunci/nilai data, lebih jelas kelebihan Predixy, jadi akhirnya kami memilih Predixy. Analisis contoh kelompok Redis

Untuk menyesuaikan diri dengan perniagaan dan persekitaran K8, kami membuat banyak perubahan pada Predixy sebelum pergi ke dalam talian dan menambahkan banyak ciri baharu, seperti penukaran dinamik Kluster Redis bahagian belakang, senarai hitam dan putih, pengauditan operasi yang tidak normal, dsb.

3. Kaedah penggunaan proksi

Disebabkan ciri-ciri penggunaan tanpa kewarganegaraan dan ringan, proksi (Proksi) digunakan sebagai kaedah penggunaan untuk menyediakan perkhidmatan melalui pengimbangan beban (LB). ) , boleh mencapai pengembangan dan pengecutan dinamik dengan mudah. Pada masa yang sama, kami telah membangunkan fungsi menukar Kluster Redis belakang untuk Proksi secara dinamik, yang boleh menambah dan menukar Kluster Redis dalam talian.

4. Kaedah pengembangan dan pengecutan automatik proksi

Kami menggunakan HPA asli K8s (Horizontal Pod Autoscaler) untuk mencapai pengembangan dan pengecutan dinamik Proksi. Apabila purata penggunaan CPU bagi semua pod Proksi melebihi ambang tertentu, pengembangan akan dicetuskan secara automatik HPA akan meningkatkan nombor replika Proksi sebanyak 1. Selepas itu, LVS akan mengesan pod Proksi baharu dan memotong sebahagian daripada trafik. Apabila penggunaan CPU melebihi ambang yang ditentukan, kapasiti akan diperluaskan Jika ia masih tidak memenuhi keperluan, logik pengembangan akan terus dicetuskan. Walau bagaimanapun, dalam masa 5 minit pengembangan yang berjaya, tidak kira betapa rendahnya penggunaan CPU, logik pengecutan tidak akan dicetuskan, sekali gus mengelakkan kesan pengembangan yang kerap dan pengecutan pada kestabilan kelompok.

HPA boleh mengkonfigurasi bilangan pod minimum (MINPODS) dan maksimum (MAXPODS) dalam kluster Tidak kira betapa rendah beban kluster, ia tidak akan dikecilkan kepada bilangan pod di bawah MINPODS. Adalah disyorkan agar pelanggan menilai keadaan perniagaan sebenar mereka untuk menentukan nilai MINPODS dan MAXPODS.

3. Mengapa Proksi

Pelanggan Redis yang menggunakan Kluster Redis perlu mengkonfigurasi sebahagian daripada IP dan Pelabuhan kluster untuk mencari pintu masuk ke Kluster Redis apabila klien dimulakan semula. Untuk nod Redis yang digunakan dalam kelompok mesin fizikal, walaupun contoh dimulakan semula atau mesin dimulakan semula, IP dan Port boleh kekal tidak berubah dan pelanggan masih boleh mencari topologi Kluster Redis. Walau bagaimanapun, untuk Kluster Redis yang digunakan pada K8s, IP tidak akan dijamin kekal tidak berubah apabila pod dimulakan semula (walaupun ia dimulakan semula pada nod K8s asal), jadi apabila klien dimulakan semula, ia mungkin tidak dapat mencari pintu masuk ke Kluster Redis.

Dengan menambahkan Proksi antara klien dan Kluster Redis, maklumat Kluster Redis dilindungi daripada klien secara dinamik perubahan topologi Kluster Redis LVS Sebagai pintu masuk, permintaan dimajukan kepada Proksi, iaitu, kelompok Redis Cluster boleh digunakan seperti versi Redis yang berdiri sendiri, tanpa memerlukan pelanggan pintar Redis.

2. Redis mengendalikan beban sambungan yang tinggi

Sebelum versi 6.0, Redis memproses kebanyakan tugas dalam satu urutan. Apabila sambungan ke nod Redis tinggi, Redis perlu menggunakan banyak sumber CPU untuk memproses sambungan ini, menyebabkan kependaman meningkat. Dengan Proksi, sejumlah besar sambungan berada pada Proksi, dan hanya beberapa sambungan dikekalkan antara Proksi dan tika Redis Ini mengurangkan beban pada Redis dan mengelakkan peningkatan dalam kependaman Redis yang disebabkan oleh peningkatan dalam sambungan.

3. Penghijrahan kluster dan penukaran memerlukan aplikasi dimulakan semula

Semasa penggunaan, apabila perniagaan berkembang, jumlah data dalam gugusan Redis akan terus meningkat apabila setiap satu nod Apabila jumlah data terlalu tinggi, masa BGSAVE akan dilanjutkan dengan banyak, mengurangkan ketersediaan kluster. Pada masa yang sama, peningkatan dalam QPS juga akan membawa kepada peningkatan dalam penggunaan CPU setiap nod. Ini perlu diselesaikan dengan menambah kelompok pengembangan. Pada masa ini, skalabiliti mendatar Kluster Redis tidak begitu baik, dan penyelesaian penghijrahan slot asli adalah sangat tidak cekap. Selepas menambah nod baharu, sesetengah pelanggan seperti Lettuce tidak akan dapat mengenali nod baharu kerana mekanisme keselamatan. Di samping itu, masa penghijrahan benar-benar tidak dapat diramalkan, dan tidak ada cara untuk kembali jika terdapat masalah semasa proses penghijrahan.

Pelan pengembangan semasa untuk kluster mesin fizikal ialah:

Buat kluster baharu atas permintaan
Gunakan alat penyegerakan untuk pindahkan data Segerakkan daripada kluster lama ke kluster baharu;
Seluruh proses adalah rumit dan berisiko, dan perniagaan perlu dimulakan semula.

4. Risiko keselamatan data

Redis melaksanakan operasi pengesahan melalui AUTH, pelanggan disambungkan terus ke Redis, dan kata laluan masih perlu disimpan pada klien. Menggunakan proksi, pelanggan hanya perlu mengakses Redis melalui kata laluan proksi dan tidak perlu mengetahui kata laluan Redis. Proksi juga mengehadkan operasi seperti FLUSHDB dan SET CONFIG, menghalang pelanggan daripada tersilap mengosongkan data atau mengubah suai konfigurasi Redis, yang meningkatkan keselamatan sistem dengan sangat baik. Pada masa yang sama, Redis tidak menyediakan fungsi pengauditan. Kami telah menambah fungsi pengelogan untuk operasi berisiko tinggi pada pelayan proksi, menyediakan keupayaan audit tanpa menjejaskan prestasi keseluruhan.

4. Masalah yang disebabkan oleh Proksi

1. Kelewatan disebabkan oleh satu lompatan lagi

Proksi adalah antara klien dan contoh Redis Apabila pelanggan mengakses data Redis, ia perlu mengakses Proksi terlebih dahulu dan kemudian satu lompatan tambahan akan meningkatkan kelewatan. Mengikut keputusan ujian, menambah satu lompatan akan meningkatkan kelewatan sebanyak 0.2~0.3ms, tetapi ini biasanya boleh diterima untuk perniagaan.

2. Pod drift menyebabkan perubahan IP

Pada K8s, proksi dilaksanakan melalui penggunaan, jadi terdapat juga masalah perubahan IP yang disebabkan oleh nod mula semula. Penyelesaian K8s LB kami dapat merasakan perubahan IP Proksi dan menukar trafik LVS secara dinamik kepada Proksi yang dimulakan semula.

3. Kependaman yang dibawa oleh LVS

Dalam ujian yang ditunjukkan dalam jadual di bawah, kependaman LVS yang diperkenalkan oleh operasi dapatkan/set dengan panjang data yang berbeza adalah kurang daripada 0.1 ms.

5 Faedah yang dibawa oleh K8s Analisis contoh kelompok Redis

1 🎜>Platform operasi dan penyelenggaraan memanggil K8s API untuk menggunakan kluster, yang meningkatkan kecekapan operasi dan penyelenggaraan.

2. Selesaikan masalah pengurusan port

Pada masa ini, penggunaan contoh Redis Xiaomi pada mesin fizikal dibezakan oleh port, dan port luar talian tidak boleh digunakan semula, iaitu Katakanlah bahawa setiap contoh Redis dalam keseluruhan syarikat mempunyai nombor port yang unik. Pada masa ini, lebih daripada 40,000 daripada 65,535 pelabuhan telah digunakan Mengikut kadar pembangunan perniagaan semasa, sumber pelabuhan akan habis dalam tempoh dua tahun. Melalui penggunaan K8, pod K8 yang sepadan dengan setiap contoh Redis mempunyai IP bebas, dan tiada masalah keletihan port dan isu pengurusan yang kompleks.

3. Turunkan ambang untuk kegunaan pelanggan

Untuk aplikasi, anda hanya perlu menggunakan versi kendiri klien bukan pintar untuk menyambung kepada VIP, yang mengurangkan ambang untuk digunakan dan mengelakkan tetapan parameter yang menyusahkan dan rumit. Aplikasi tidak perlu mengendalikan sendiri topologi Kluster Redis kerana VIP dan port ditetapkan secara statik.

4 Meningkatkan prestasi pelanggan

Menggunakan pelanggan bukan pintar juga boleh mengurangkan beban pada klien, kerana pelanggan pintar perlu mencincang kunci pada klien untuk menentukan Manakah Redis nod permintaan yang dihantar akan menggunakan sumber CPU mesin klien apabila QPS agak tinggi. Sudah tentu, untuk memudahkan migrasi aplikasi pelanggan, kami turut menjadikan Proksi menyokong protokol pelanggan pintar.

5. Naik taraf dinamik dan pengembangan dan pengecutan

Proksi menyokong fungsi menambah dan menukar Kluster Redis secara dinamik, supaya proses pensuisan kluster dan pengembangan Kluster Redis boleh dilakukan dengan betul. Sebagai contoh, bahagian perniagaan menggunakan Kluster Redis 30-nod Disebabkan peningkatan dalam volum perniagaan, volum data dan QPS telah meningkat dengan cepat, dan saiz kluster perlu digandakan. Jika kapasiti dikembangkan pada mesin fizikal asal, proses berikut diperlukan:

Selaraskan sumber dan gunakan gugusan baharu 60 nod; 🎜> Alat pemindahan konfigurasi manual untuk memindahkan data kluster semasa kepada kluster baharu; topologi dan mulakan semula perkhidmatan.
Walaupun Kluster Redis menyokong pengembangan dalam talian, penempatan semula slot semasa proses pengembangan akan memberi kesan kepada perniagaan dalam talian, dan masa migrasi tidak dapat dikawal, jadi kaedah ini jarang digunakan pada masa ini. Peringkat ini hanya digunakan sekali-sekala apabila sumber tidak mencukupi.

Juga buat alat penyegerakan kluster dengan satu klik melalui antara muka API untuk memindahkan data ke kluster baharu

Naik taraf kluster juga sangat mudah: jika pihak perniagaan boleh menerima gangguan kelewatan tertentu, ia boleh dilaksanakan melalui naik taraf rolling StatefulSet semasa waktu luar puncak jika perniagaan mempunyai keperluan untuk kelewatan, data boleh dipindahkan dengan mencipta cara kluster baharu untuk mencapainya.
6. Tingkatkan kestabilan perkhidmatan dan penggunaan sumber

6. Masalah yang dihadapi

1 Pod restart membawa kepada kehilangan data

K8s pod ranap Apabila masalah dimulakan semula, kerana kelajuan mula semula terlalu pantas, pod akan dimulakan semula sebelum gugusan Kluster Redis ditemui dan induk ditukar. Jika Redis pada pod adalah hamba, ia tidak akan memberi kesan. Tetapi jika Redis adalah tuan dan tiada AOF, semua data memori asal akan dikosongkan selepas dimulakan semula Redis akan memuatkan semula fail RDB yang disimpan sebelum ini, tetapi fail RDB bukan data masa nyata. Kemudian, hamba juga akan menyegerakkan datanya sendiri ke cermin data dalam fail RDB sebelumnya, yang akan menyebabkan beberapa kehilangan data.

Apabila menggunakan StatefulSet, nama Pod mengikut format penamaan tertentu dan mengandungi nombor tetap, jadi StatefulSet ialah perkhidmatan stateful. Apabila kami memulakan Kluster Redis, kami menetapkan pod bernombor bersebelahan kepada hubungan tuan-hamba. Apabila memulakan semula pod, tentukan hambanya melalui nama pod Sebelum memulakan semula pod, hantar perintah failover kelompok ke nod hamba untuk memaksa nod hamba yang masih hidup menjadi induk. Dengan cara ini, selepas dimulakan semula, nod akan secara automatik menyertai kluster sebagai nod hamba.

Kelewatan pemetaan LVS

Pod proksi diseimbangkan melalui LVS Terdapat kelewatan tertentu untuk LVS berkuat kuasa pada pemetaan IP:Port bahagian belakang Nod di luar talian secara tiba-tiba akan menyebabkan beberapa sambungan terputus. Untuk meminimumkan kesan operasi dan penyelenggaraan Proksi pada perniagaan, kami telah menambahkan pilihan berikut pada templat penggunaan Proksi:

lifecycle:    preStop:      exec:        command:        - sleep        - "171"

Salin selepas log masuk

Untuk pod Proksi biasa di luar talian, seperti pengurangan kelompok, kemas kini bergulir versi Proksi dan lain-lain Apabila pod yang dikawal oleh K8s berada di luar talian, ia akan menghantar mesej kepada LVS dan menunggu selama 171 saat sebelum pod di luar talian. Kali ini sudah cukup untuk LVS menukar trafik pod ini secara beransur-ansur kepada pod lain tanpa sebarang kesedaran perniagaan itu.

2. K8s StatefulSet tidak dapat memenuhi keperluan penempatan Redis Cluster

K8s native StatefulSet tidak dapat memenuhi sepenuhnya keperluan penempatan Redis Cluster:

Dalam Redis Cluster , nod dengan perhubungan induk-siap sedia tidak boleh digunakan pada mesin yang sama. Ini mudah difahami Jika mesin rosak, serpihan data akan menjadi tidak tersedia.

2) Kluster Redis tidak membenarkan lebih separuh daripada nod induk dalam gugusan gagal, kerana jika lebih separuh daripada nod induk gagal, tidak akan ada undian nod yang mencukupi untuk memenuhi keperluan protokol gosip. Oleh kerana induk dan sandaran Kluster Redis boleh ditukar pada bila-bila masa, kami tidak boleh mengelakkan situasi bahawa semua nod pada mesin yang sama adalah nod induk, jadi semasa penggunaan, kami tidak boleh membenarkan lebih daripada 1/4 daripada nod dalam gugusan untuk digunakan pada mesin yang sama.

Untuk memenuhi keperluan di atas, StatefulSet asli boleh menggunakan fungsi anti-afiniti untuk memastikan kelompok yang sama hanya menggunakan satu nod pada mesin yang sama, tetapi penggunaan mesin ini sangat rendah.

Jadi kami membangunkan CRD berdasarkan StatefulSet: RedisStatefulSet, yang menggunakan pelbagai strategi untuk menggunakan nod Redis. Menambah beberapa fungsi untuk mengurus Redis dalam RedisStatefulSet. Kami akan terus membincangkan perkara ini secara terperinci dalam artikel lain.

7 Ringkasan

Berpuluh-puluh kluster Redis telah digunakan dan dijalankan pada K8 selama lebih daripada enam bulan, dan kluster ini melibatkan berbilang perniagaan dalam kumpulan. Terima kasih kepada penggunaan pantas dan keupayaan penghijrahan kesalahan K8, beban kerja operasi dan penyelenggaraan gugusan ini jauh lebih rendah daripada gugusan Redis pada mesin fizikal, dan kestabilannya telah disahkan sepenuhnya.

Kami juga menghadapi banyak masalah semasa proses operasi dan penyelenggaraan. Banyak fungsi yang dinyatakan dalam artikel telah diperhalusi berdasarkan keperluan sebenar. Dalam proses berikut, banyak masalah masih perlu diselesaikan secara beransur-ansur untuk meningkatkan kecekapan penggunaan sumber dan kualiti perkhidmatan.

1. Arahan bercampur Vs. Arahan bebas

Aplikasi Redis bagi mesin fizikal digunakan secara berasingan bermanfaat kepada pengurusan, tetapi kadar penggunaan sumber tidak tinggi. Kejadian Redis menggunakan CPU, memori, dan rangkaian IO, tetapi ruang storan pada dasarnya dibazirkan. Apabila tika Redis digunakan pada K8, sebarang jenis perkhidmatan lain boleh digunakan pada mesin di mana ia berada Walaupun ini boleh meningkatkan penggunaan mesin, untuk perkhidmatan seperti Redis yang mempunyai keperluan ketersediaan dan kependaman yang tinggi, jika Diusir. kerana mesin kehabisan memori tidak boleh diterima. Ini memerlukan kakitangan operasi dan penyelenggaraan untuk memantau memori semua mesin di mana kejadian Redis digunakan Setelah memori tidak mencukupi, mereka akan memotong induk dan memindahkan nod, tetapi ini akan meningkatkan beban kerja operasi dan penyelenggaraan.

Jika terdapat aplikasi pemprosesan rangkaian tinggi yang lain dalam penggunaan hibrid, ia juga mungkin memberi kesan negatif pada perkhidmatan Redis. Walaupun fungsi anti-afiniti K8 boleh menggunakan contoh Redis secara selektif pada mesin yang tidak mempunyai aplikasi sedemikian, keadaan ini tidak dapat dielakkan apabila sumber mesin sempit.

2. Pengurusan Kluster Redis

Kluster Redis ialah seni bina kluster P2P tanpa nod pusat Ia bergantung pada protokol gosip untuk menyebarkan, menyelaras dan membaiki status secara automatik daripada kelompok. Nod pergi dalam talian dan luar talian Masalah rangkaian boleh menyebabkan masalah dengan status beberapa nod dalam Kluster Redis Sebagai contoh, nod dalam status gagal atau berjabat tangan mungkin muncul dalam topologi kluster. Untuk keadaan tidak normal ini, kami boleh menambah lebih banyak fungsi pada Redis CRD untuk menyelesaikannya secara beransur-ansur dan meningkatkan lagi kecekapan operasi dan penyelenggaraan.

3. Audit dan keselamatan

Redis hanya menyediakan fungsi perlindungan pengesahan kata laluan Auth dan tiada pengurusan kebenaran, jadi keselamatan agak rendah. Melalui Proksi, kami boleh membezakan jenis klien melalui kata laluan Pentadbir dan pengguna biasa menggunakan kata laluan yang berbeza untuk log masuk, dan kebenaran operasi boleh laku juga berbeza, supaya fungsi seperti pengurusan kebenaran dan pengauditan operasi dapat direalisasikan.

4. Menyokong berbilang Kluster Redis

Disebabkan oleh pengehadan protokol gosip, satu Kluster Redis mempunyai kebolehskalaan mendatar yang terhad Apabila skala kluster ialah 300 nod pemilihan nod adalah sukar Kecekapan perubahan topologi kelas berkurangan dengan ketara. Pada masa yang sama, memandangkan kapasiti satu contoh Redis tidak seharusnya terlalu tinggi, sukar bagi satu Kluster Redis untuk menyokong skala data lebih daripada TB. Melalui Proksi, kami secara logiknya boleh memecah kekunci, supaya satu Proksi boleh disambungkan kepada berbilang Kluster Redis Dari perspektif pelanggan, ia adalah setara dengan menyambung ke gugusan Redis yang boleh menyokong skala data yang lebih besar.

Atas ialah kandungan terperinci Analisis contoh kelompok Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!