基于浪潮K1 Power的Redis集群容器云平台测试报告

Posted 2021-07-03 浪潮商用机器

【导读】某行多个Redis集群的运维管理，存在版本管理难、新集群部署慢、资源隔离差等问题，Redis容器化的好处非常多，但是结合到具体应用场景还有一些问题需要验证。本文介绍了选用基于 浪潮K1 Power Linux的容器云平台解决方案，进行Redis数据库容器云应用（大数据平台领域）测试的过程和测试结果，对有类似应用场景和需求的企业具有参考意义。

【作者】杨梦伦，现任某国有银行信息科技部工程师，负责系统运维，擅长开源软件、大数据、容器平台相关技术。喜欢开源，曾经做过开发，接触过安全，擅长研究。

1.背景和需求

近年来，我行互联网金融业务发展迅速，网上银行、手机银行业务量成倍增加，井喷式增长的客户在线访问量和大数据高并发的访问需求，给电子银行相关系统带来了很大的挑战。比如在互联网金融业务场景中，常见的营销模式：秒杀，经常会出现的问题包括：并发太高导致程序阻塞；库存无法有效控制，出现超卖的情况。我们采用异步、缓存这两种手段来解决系统压力问题。前者，例如说内存队列（例如说 JDK Queue、Disruptor 等）、分布式队列（例如说 RabbitMQ、RocketMQ、Kafka），更多适合写操作。后者，例如说内存缓存（例如说 JDK Map、EhCache 等）、分布式缓存（例如说 Redis、Memcached 等），更适合读操作。本文重点谈论后者中的Redis，目前我行已经有很多系统采用了Redis集群作为数据缓存层和消息队列，采用三主三从6节点的架构。多个Redis集群的运维管理，主要有以下三个方面的问题：

版本管理难：Redis之前是直接部署在物理机上，各个版本的Redis非常分散而且不容易维护。

新集群部署慢：需要手动修改很多配置文件再逐个部署节点，初始化工作需要较长时间。

资源隔离差：当前的Redis集群部署在物理机集群上，多业务线的Redis集群有混布的情况。由于没有做CPU的资源隔离，经常出现某Redis节点CPU使用率过高导致其他Redis集群的节点争抢不到CPU资源引起时延抖动。因为不同的集群混布，这类问题很难快速定位，影响运维效率。

为了简化大规模Redis集群的运维管理工作，我行对新的技术手段展开调研。容器镜像天然支持标准化，与硬件无关，可以解决版本的问题，K8通过StatefulSet部署Redis集群，使用configmap管理配置文件，新集群部署时间只需要几分钟，大大提高了运维效率。Redis容器化的好处非常多，但是结合到我行具体应用场景还有一些问题需要验证，我们希望在测试Redis数据库容器云应用（大数据平台领域）时了解以下方面：

1. Redis容器化以后与原来相比，性能读写，响应时间，网络流量有多大差距？

2. 访问Redis采用ip和端口，并且主从不能在一台宿主机上，如何解决以上问题？

3. Redis的配置文件和数据持久化如何在容器环境中保存？

4. 主节点宕机时，Redis会自动将从节点转换为主节点，此时若k8s将原来主节点拉起会导致数据冲突。  

2.测试方案设计

测试环境的设计，我们真实模拟生产环境，采用了典型的三主三从6节点的架构，用6台虚拟机，每台机器作为OpenShift Container Platform（OCP）集群的一个worker节点，每个worker只启动一个pod实例，最大利用主机资源，同时Redis集群的架构与生产环境完全一致。生产环境的Redis集群是在应用层面对集群的各个节点做负载均衡和路由，集群运维难度大、成本高，所以在测试环境设计上，我们做了优化，采用中间件haproxy自动负载均衡，这样Redis集群对于前端应用来说透明，维护会比较简单。

在测试容器化Redis时选用浪潮K1 Power与红帽OpenShift推出的容器云平台联合解决方案，该方案面向企业级客户在容器平台部署方面的需求，是可伸缩的，简化的以及快速的一个部署环境，经过浪潮和红帽严格的环境测试和官方认证，在使用这样一个软硬件环境的情况下，可以明显减少本次测试工作部署方面投入的时间和成本。

3.容器云集群架构

OCP集群信息：

NODE		CPU	MEM	IP
物理压力机(K1 Power Linux  FP5280G2)		128C	128G	10.152.15.42
Openshift Container Platform（OCP）	Console	16C	16G	10.152.20.31
	Master01	16C	64G	10.152.20.33
	Master02	16C	64G	10.152.20.34
	Master03	16C	64G	10.152.20.35
	Worker01	16C	64G	10.152.20.41
	Worker02	16C	64G	10.152.20.42
	Worker03	16C	64G	10.152.20.43
	Worker04	16C	64G	10.152.20.44
	Worker05	16C	64G	10.152.20.45
	Worker06	16C	64G	10.152.20.46

软件版本：

软件	版本号
Redis	6.05
Haproxy	1.5.18
Openshift Container Platform（OCP）	4.3

集群说明：

OCP 集群部署在K1 Power Linux 服务器FP5290G2 创建的虚机上。

Redis集群采用三主三从模式，六个Redis容器实例pod分别部署在OCP集群的六个worker节点上。

Redis作为有状态服务，通过statefulset统一部署集群6个pod。

Redis集群持久化采用PVC实现远程文件存储（nfs）到Console节点。

基于Redis cluster集群内部数据请求重定向后会新建tcp连接，所有pod的ip外部需要访问到，这里实现pod的网络模式为hostnetwork,共用宿主机worker的网络接口和ip。

集群前端搭建haproxy实现负载均衡。

架构拓扑图如下：

4.高可用Redis集群部署

1)ssh登录OCP 集群console节点。

2)创建project

oc new-project Redis-cluster-test

3)创建PV

进到工作目录（自行创建）

oc create -f pv.yaml

pv.yaml参考文件：https://github.com/powerlsr/redis-on-ocp/blob/main/pv.yaml

共创建6个PV，Redis集群6个节点会各分配一个，其中：

server: 10.152.20.31

path: /home/share/Redis-cluster-test/n{0-5}

server表示nfs server ip，这里设置为console节点ip

path需要手动创建                   

4)Console节点主机设置启动nfs服务

yum install –y nfs-utils

cat >> /etc/exports << EOF

/home/share/Redis-cluster-test/n0 *(insecure,rw,async,no_root_squash)

/home/share/Redis-cluster-test/n1 *(insecure,rw,async,no_root_squash)

/home/share/Redis-cluster-test/n2 *(insecure,rw,async,no_root_squash)

/home/share/Redis-cluster-test/n3 *(insecure,rw,async,no_root_squash)

/home/share/Redis-cluster-test/n4 *(insecure,rw,async,no_root_squash)

/home/share/Redis-cluster-test/n5 *(insecure,rw,async,no_root_squash)

EOF

service nfs restart

service rpcbind restart

5)在project Redis-cluster-test中创建ConfigMap

Console节点主机执行命令：

oc create -f configmap.yaml -n Redis-cluster-test

configmap.yaml参考：https://github.com/powerlsr/redis-on-ocp/blob/main/configmap.yaml

如果对Redis配置有要求，可以修改这个文件中的Redis.conf项

6)在project Redis-cluster-test中配置安全策略

Console节点主机执行命令：

oc adm policy add-scc-to-user anyuid  -z default -n Redis-cluster-test

oc adm policy add-scc-to-user privileged -z default -n Redis-cluster-test

oc adm policy add-cluster-role-to-user cluster-reader -z default -n Redis-cluster-test

7)在project Redis-cluster-test中创建statefulset

oc create -f sts.yaml

sts.yaml文件参考：https://github.com/powerlsr/redis-on-ocp/blob/main/sts.yaml

8)查看已创建的Redis 集群对象

oc get pods -n Redis-cluster-test

oc get pv -n Redis-cluster-test

oc get pvc -n Redis-cluster-test

9)登录web界面确认创建对象

登录后查找statefulset:

点击Redis-cluster后选择Pods标签：

可以看到有6个pod已经running，分别分布到6个worker节点，点击其中任意一个，查看POD_IP：

可以看到pod ip使用的是宿主机worker节点的ip， 说明集群外部网络是可以直接通过IP访问pod的。

10)启动Redis 集群

登录Console主机：

Redis-cli  --cluster create 10.152.20.41:6379 10.152.20.42:6379 10.152.20.43:6379 10.152.20.44:6379 10.152.20.45:6379 10.152.20.46:6379 --cluster-replicas 1

11)验证集群功能

登录Console主机：

Redis-cli -h 10.152.20.41 –c

12)在压力主机上搭建haproxy

主机ip: 10.152.15.42

yum install –y haproxy

/etc/haproxy/haproxy.cfg参考：

Harpoxy监听端口4306.

启动haproxy:

haproxy -f /etc/haproxy/haproxy.cfg

验证：

Redis-cli -h 10.152.15.42 -p 4306 -c

5.测试过程设计

1)Redis容器VS非容器性能对比

使用Redis-benchmark工具进行压力测试，Console节点安装Redis:6.0.5版本，Console节点部署Docker容器Redis:6.0.5版本：非容器Redis端口6379，Redis-Docker映射本机端口6380.

客户端主机ip:10.152.15.42

非容器化Redis集群压力测试结果：

模拟100并发，100000个请求

登录10.152.15.42：

Redis-benchmark -h 10.152.20.31 -c 100 -n 100000：

容器化Redis集群压力测试结果：

测试结果显示，Redis集群在K1 Power容器化和非容器化场景下性能差异不大。

2)集群节点独立部署

根据测试目标，参照第四章节把Redis集群的三主三从节点部署到容器云平台不同的worker节点上面，实现了Redis集群主从节点的独立部署。

3)数据持久化

Redis集群的持久化使用容器云平台nfs远程存储，共创建6个PV，Redis集群6个节点会各分配一个，path需要手动创建。

4)failover测试

查看当前Redis cluster集群master slave 分布情况：

登录console节点，执行命令：

Redis-cli -h 10.152.15.42 -p 4306 -c

查看pods分布情况：

模拟删掉master节点10.152.20.45:6379所在pod Redis-cluster-1，目前Redis集群检查心跳时间为2秒（cluster-node-timeout 2000，小于pod自动拉起时间），检查slave节点10.152.20.41:6379是否自动升级为master节点，原有master节点下降为slave节点：

主动切换正常。

从测试结果可以看到，删除Redis集群中一个master对应的pod，相当于该master节点不能提供服务，这个master对应的slave自动升级成master节点，OCP把挂掉的pod拉起来，自动成为slave。

6.测试总结

本次测试，模拟生产环境Redis集群架构，实现了高可用集群实例在容器云平台worker节点上的独立部署，外部应用节点可以通过IP和端口访问Redis高可用集群；并使用容器云平台nfs存储为Redis集群提供了配置信息等关键信息的持久化；并验证通过主从节点的failover自动快速切换。浪潮K1 Power与红帽OpenShift容器云平台联合方案，为本次测试提供了性能卓越、稳定的运行平台，其中Redis集群容器化部署表现出与非容器部署接近的性能，达到了预期的效果。OpenPOWER生态系统为我们的测试提供了各种开放的软硬件选择，简单顺畅的完成整体方案部署。K1 Power Linux FP5290G2服务器采用POWER9处理器，相比于x86平台提供更快的内核和更多的线程，处理器有22个核心，支持SMT4；具有更宽更快的内存接口，支持8个内存通道，内存容量支持2TB。在测试中表现出更高的吞吐和更低的延迟，运行的容器实例密度更高，性能更好，整体方案性价比高。

点击文末阅读原文，可以到原文下留言交流

觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到

 资料/文章推荐：

• 
  

扫描下图二维码

查阅产品资料、解决方案、成功案例

预约活动与直播培训课程