驾驭千级节点——揭秘PUMA大规模集群能力（四） ---- 云上测试及结论

前面的博客说了一大堆，光说不干怎么行呢，下面就干起来，我最近一直在华为云上进行PUMA大规模集群能力验证及测试，这里把测试过程及测试结果总结一下。

1.1 测试目地

1、  测试puma集群的规模能否部署到1000节点 （PaaS需求）

2、  测试单个puma集群的TPS能否达到1000w，消息大小为2k (消费者云需求)

3、  随着puma节点的增加，集群tps的变化曲线是如何的

4、  海量topic ，平均单节点上有100个topic、每个topic配置为3副本、3分区、高可靠场景，集群的tps性能如何

1.2 测试环境

测试环境选择为华为云，主要有以下两点原因

1、需要测试的规格太大，当前的实验室环境已经无法满足上千万TPS的测试规模，之前所有可用机器加起来组成的集群规模，也仅仅测试了上百万TPS。

2、公有云的测试环境更符合下游产品用户使用的真实场景，测试出来的数据比单纯的实验室数据更有说服力。

1.3 硬件环境

根据企业云上申请机器的规模及相应的配置信息如下：

机器属性

硬件配置

部件

虚拟机

4C16G，需要单独的数据盘

kafka

虚拟机

2C8G

zookeeper

虚拟机

千兆网卡

网卡

1.4 软件环境

软件列表

详细版本说明

备注

Zookeeper

zookeeper-3.4.6.tar

PUMA

V1R1C003

选型为kafka 0.9.0.1

JDK

1.8.0_91

expect

系统自带即可

编码脚本使用

pdsh

分布式运维工具

nmon

服务器资源信息收集工具

1.5 公有云测试过程中的注意事项

1、公有云的特点

从使用情况看，公有云上申请的机器都是虚拟机，站在用户角度，实在不清楚机器源是否来自同一台物理机，这样对于硬件资源的分析上，很难判断机器资源是否处于饱和状态，在一定程度上会影响测试结论的判断，只能多次从测试角度不断尝试去证明测试结论，这样在测试结果分析上，具有一定的不确定性。

公有云由于部署在外部网络上，需要从跳板机跳转，在机器之间的安全鉴权上耗时比较长，所以在机器之间的免密处理上，如果有超时时间，注意适当增加下，否则很容易超时而失败。

公有云默认的机器配额是有限制的（包括IP和硬盘资源），只有20台，所以在测试前需要预估清楚需要的测试规模，提前走工单申请好对应的机器资源，规划好对应的子网，不然临时申请和规划，影响整个测试进度。

2、应对公有云，测试需要做的整改

公有云测试，由于各种不确定性，肯定需要调整测试模型的，所以测试环境自动部署是上云之前首先要满足的必要条件，环境自动部署在上云前实验室调试都是没问题的，而且都已经上CI运行了，但是到了公有云后，自动部署不能完全跑起来，以下是整个应对公有云测试上，测试方面根据公有云做的整改，作为经验总结下。

3、使用私有镜像

刚开始确实不清楚公有云提供的公有镜像为何不能用，直到使用后才知道，公有镜像一般都做了防火墙策略，很多端口默认不开放，导致集群之间无法互通，不建议使用公有镜像，不然出现一堆问题还得定位，建议使用平时测试对应的系统做的私有镜像，可以联系对应的客服操作。

4、需要独立的机器做控制节点

当前公有云环境上的跳板机的系统是缺少不少组件的，导致免密是无法执行的，这样什么后果呢，从该机器操作余下的机器几乎就是不可能了，改造跳板机之前也尝试过，失败了，所以当时的处理方式就是多申请一个机器作为控制节点，以此节点作为控制机，与余下的机器做免密，来统一操作余下的机器。

这个控制节点的配置可以不需要太高，所有需要用的公共文件都保存在上面，需要长期保留，后续可以节省重新申请的时间。

5、一次申请的机器数量不要太多

公有云机器申请后是慢慢依次创建的，中间有个过程，不是一蹴而就。如果申请的机器数量太多，一来时间太长，影响部署配置文件的准备；二来不是每次申请所有机器都是成功的，可能总有那么几个失败的机器，原因我也不太清楚，最痛苦的就是从茫茫机器中找失败机器的IP（公有云特点：IP都是依次创建下来的，所以我们在制作机器配置文件的时候可以直接刷下来，但是中间有几个失败的就不妙了，我们得找到然后删除，不然自动部署会失败，纯粹浪费其他机器的部署时间），经验值一次申请不要超过50个，申请页面最大显示的记录是50条，有错误也容易看出来。

6、免密脚本失败能自动重试

前面有提到公有云部署在外部网络上，需要从跳板机跳转，在机器之间的安全鉴权上耗时比较长，从环境部署情况来看，不出意外，单台机器免密需要耗时1分钟，如果由于网络原因导致的免密失败，则需要重复执行，还得重复耗时1分钟，时间还是挺长的，所以这里为了应对这种概率性的免密失败，脚本需要支持自动重试，否则机器数量太多，手工不好再次操作。

7、修改系统文件减少登陆时间

这里选用的系统为suse11 SP3，需要修改两个系统文件屏蔽掉域名解析部分，以减少登陆时间，不然即使做了免密，使用SSH登陆还是会比较耗时，具体方法如下：

vim /etc/hosts

注释多余的127.0.0.1信息

127.0.0.1 kafka-0004

#127.0.0.1 host-192-168-1-189

#127.0.0.1 host-192-168-1-183

#127.0.0.1 host-192-168-1-42

#127.0.0.1 host-192-168-101-87

#127.0.0.1 host-192-168-101-69

vim /etc/resolv.conf

全部注释

8、依赖的三方软件在测试前需要安装好

公有云系统上面是没有多余软件存在的，测试程序所依赖的所有三方软件需要自己安装，否则测试过程出现问题还需要耗时定位，影响测试效率。

9、申请的数据盘需要自己手工进行挂接

性能测试对于磁盘读写是有要求的，一般情况下，存储和系统最好分离，以免频繁读写磁盘会对系统造成冲击，所以主测环境一般会申请额外的数据盘进行数据存储，注意：公有云上单独申请的硬盘需要自己手工挂接，否则无法使用。

公有云系统如果申请时候使用同一系统，则数据盘挂接方式基本一致，可以采用同样的脚本实现自动化挂接，提升测试效率。

10、测试结果自动化处理

由于公有云测试规模比较大，所以需要收集的测试结果比较多，这里对于需要收集的测试数据一定想办法自动化处理，否则数据处理巨大，影响测试效率。

1.6 性能测试结果分析

公有云之前也有提过申请的机器都是虚拟机，实在不清楚机器源是否来自同一台物理机，这样对于硬件资源的分析上，很难判断机器资源是否处于饱和状态，对于收集到的硬件资源文件，一些资源的占用率往往与在实验室测试有一定差距，那如何分析呢，可以多抽取几个系统资源文件查看和对比，如果各个文件的数据均不一致，说明服务器端系统资源还有冗余，可以考虑增加一些客户端，看是否可以提升TPS，尽量往实验室已有的测试数据靠近；而实际测试出来的数据有差距是正常的，我们得先排除系统资源是否饱和，再来找测试系统本身的问题。

1.7 现网组网

在华为云上直接创建虚拟私有云，然后在虚拟私有云中创建多个虚拟子网，具体的过程就不介绍了，有兴趣的童鞋可以自己去华为云上玩一玩

1.8 测试组网

1.9 消息配置

在测试过程中，如果不做特别说明，消息的大小均为2K，场景分为高吞吐和高可靠，其中高吞吐的配置一般为1副本，1分区，ack=1，异步落盘；高可靠配置一般为3副本，3分区，ack=all，min.insync.replicas=2，异步落盘。

另外，在测试过程中，统计tps的模式和kafka自带的kafka-producer-perf-test.sh脚本有所不同，自带的脚本是消息发送了就立马统计tps，而我们的测试脚本是消息收发后，等收到了消息发送成功的回调再来统计tps，这样的话，相同条件下统计的tps可能比kafka自带的脚本统计出来的tps略低，但是统计的结果会更准确。

1.10 千节点集群

1.10.1 搭建千级的kafka集群

在华为云上搭建1000个kafka节点的集群，整个部署时间5小时左右，集群能正常搭建，消息能正常收发。

1.10.2 千级节点集群的性能

受限与华为云配额的限制，如果搭建了千节点的集群，那么可供使用的客户端只有200多台了，这种情况下是无法测试出集群的tps性能的，通过后面其他的测试，这里可以给一个预估值：

在kafka节点和客户端节点的比例为1:1的情况下，1000节点集群能提供的tps约为1100w（消息大小2K，高吞吐场景）

如果客户端节点数量足够，在和合理的比例下，集群中单节点的性能能达到4.8w的tps，则千节点集群的tps可以达到4800w（消息大小2K，高吞吐场景）。

1.10.3 小结

1、  千节点的集群可以正常工作，消息收发正常

2、  千节点集群中，zk不是瓶颈，3节点的zk即可满足，但是节点的内存不能太低4G即够用

3、  千节点集群的tps受限于测试机器的数量，无法准确给出，这里可以给一个大的范围：1100w --- 4800w之间

4、  千节点集群运行过程中，创建和删除topic不会影响其他topic的性能，但是加入节点或者移除节点会稍微影响集群的tps性能。

1.11 千万tps

1.11.1 理论分析

按照一般的规律，整个集群的tps会随着集群节点数量的扩大而增长，有可能是线性增长，也有可能不是，或者节点数量达到一定规模后，再增加节点，集群的tps反而下降，因此，我这边的测试就是通过不断增加kafka的节点数来测试其tps，找出最少需要多少节点就能达到千万tps的规模。

1.11.2 测试

在测试过程中，受限于配额，最初使用的是1:1的模型，就是kafka节点数和客户端节点数的数量一致，测试的数据如下：

从图中可以看到，当机器节点规模达到500时，整个集群的tps能达1249w。

后面调整了kafka节点和客户端节点的比例，增加了客户端的数量，测试的数据如下：

从图中可以看到，通过修改kafka节点和客户端节点的数量，200个kafka节点的集群就能达到987w的tps，而300个节点的集群在未压满的情况下能达到1203wtps。

1.11.3 小结

1、  kafka集群通过增加节点数量和客户端数量，可以达到千万tps的规模

2、  达到千万tps规模所需要的最少节点数量为205台左右

1.12 集群tps随节点数量的变化

1.12.1 理论分析

这个在测试前，想到了两种可能性

1、  在一定的集群规模下，集群tps随节点数量线性变化，就是增加一个节点会带来固定的tps的增长

2、  集群tps随节点数量的增加而增加，但不是线性增长，同时，集群扩大到一定的规模后，再增加节点，集群tps不会增加，反而有可能下降

1.12.2 测试

部分测试数据入下：

上图表明，在kafka节点数和客户端数为1:1的情况下，集群单个节点的平均tps是逐步减小的，而且，在1000个节点以内，随着集群内节点的增加，集群总的tps是成上升趋势，最大tps为1100w。

另一种测试的数据如下：

在客户端数量充足且和kafka节点保持特定比例的情况下，集群内单节点的性能基本维持在4.9w左右，随着节点数量的增加，集群总的tps线性增长；但是不同规模集群达到最大tps所需要的客户端数量不一样。下面给出一个曲线，如下：

注：最后一组数据300节点的tps未压满

1.12.3 小结

1、  在puma节点和客户端节点数量为1:1的情况下，随着集群节点的增加，集群内单个节点的平均tps逐步下降，集群总的tps缓慢上升，当集群规模达到千节点时，集群内单个节点的平均tps为1.1w，总的tps为1100w。

2、  不管多大规模的集群，在千兆网卡环境下，其单节点的平均tps上限均为5w，严格来说是4.9w左右

3、  不同规模集群的tps达到上限所需要的client数比例也不同，但是，只要有合适的topic比例和足够的客户端数量，另外，增加topic数量，测试过程中使用的比例为broker : topic为1:6；集群内单个节点的平均tps可以达到4.9w，使得集群tps随着节点的增加实现线性增长

1.13 海量topic场景

1.13.1 场景背景

该场景主要是paas的多topic场景，集群内平均每个节点上的topic比较多，topic配置为3副本，3分区，高可靠配置，min.insync.replicas=2 ，flush.messages=1

主要测试节点上平均不同topic数情况下，集群的tps变化

1.13.2 测试

测试集群的规模为100节点，客户端数量为1200个，测试的数据如下：

从上图可以看出，在海量topic且高可靠的场景下，100节点集群的tps基本在100w左右，同时，在50 100 200topic这三个场景下，topic数越多，集群的tps越低，这说明增加topic会降低集群的tps。

1.14 测试总结

1、  单个puma集群最大支持的节点数受限于测试环境，无法准确给出；但是测试过程中成功搭建过1000节点的集群，可以正常工作，收发消息、添加删除topic都OK。

2、  不同数量节点的PUMA集群，可以通过调整topic数和连接的client数来使集群的tps达到上限，同时使集群tps随着节点数量的增加而呈线性增长；在公有云的千兆网卡、消息大小2K、高吞吐的配置下，单个节点的tps上限为4.9w，就是说集群每增加一个节点，其总的tps会增加4.9w左右，下图是一个变化趋势：

在这中配置下根据变化趋势，1000节点集群的tps将达到4800w左右

3、  单个集群达到千万tps很容易，最少200个节点+1700个客户端就可以达到千万tps的要求。

1.15 部分测试截图

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。