测试环境准备:硬件资源要求、操作系统配置、网络拓扑、安全组规则

在跑 HSM SDK 压力测试之前,环境准备工作要是没做好,后面全白干。我记得有一次帮客户排查性能瓶颈,折腾了一天,最后发现是网卡中断没绑核——类似这种坑,我踩过不少。所以这章我把常见问题提前讲清楚。

硬件资源要求

先说说硬件。很多同学觉得压力测试嘛,机器越猛越好。其实不一定。关键在于找到瓶颈在哪。我个人习惯把资源分成四块来看:

资源类型推荐最低配置我的建议值(中负载)避坑点
CPU4 核 2.0 GHz8 核 3.0 GHz 以上注意 Turbo Boost 关掉,保障频率稳定
内存8 GB16~32 GBHSM 本地缓存会吃内存,JVM 也要预留
磁盘100 GB 机械盘NVMe SSD 500 GB日志不要写同盘,压测时 IO 会爆炸
网络接口千兆万兆 + 多队列网卡RSS 要打开,否则单核软中断打满

一个小技巧:如果预算有限,优先上好网卡和 SSD。CPU 慢一点最多 TPS 低一些,但 IO 瓶颈会导致测试结果剧烈抖动,完全没法看。

另外,如果你准备跑分布式测试(多台压测机连一个 HSM 集群),每台压测机之间最好用独立交换机或 VLAN 隔离。我曾在项目中遇到过压测流量和线上业务流量混跑,压到一半线上告警了……嗯,从那以后我都是单独拉测试网段。

操作系统配置

系统配置这块,说白了就是让操作系统别在关键时候掉链子。下面几项我几乎每次都会调。

内核参数

主要调网络协议栈和互斥锁相关参数。拿出你的 root 权限:

# /etc/sysctl.conf 追加以下内容
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_fin_timeout = 15
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
kernel.sem = 250 32000 100 128
vm.max_map_count = 655360

记得 sysctl -p 生效。你想想看,如果 HSM 调用并发一上来,socket backlog 默认128,瞬间队列就满了,客户端直接 connection refused。我最初自己写压测脚本时就踩过这个坑。

ulimit 与文件句柄

每个压测进程需要打开多个连接(HSM 会话 + 日志文件 + 监控 socket),默认 1024 个文件描述符远远不够。

# /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576
* soft nproc 65536
* hard nproc 65536

注意:有些发行版(比如 CentOS 7)还需要修改 /etc/systemd/system.conf 里的 DefaultLimitNOFILE,否则 systemd 启动的进程不会继承 limits.conf 的配置。我就因为这个配了三次才发现没生效……

时间同步

HSM 的日志和审计记录都有时间戳。多台压测机时间不同步,你后面分析延时分布时,数据全乱了。建议用 chrony,别再用 ntpdate 了:

# 安装并启动
yum install chrony -y
systemctl enable chronyd
systemctl start chronyd
chronyc sources -v

我个人习惯在每台压测机上写一个监控脚本,每 5 分钟检查一次时钟偏移,超过 50ms 就报警。

网络拓扑

网络拓扑怎么搭,取决于你压测的对象。这里我画了一张常用的部署结构图,你一看就明白。

HSM SDK 压力测试环境拓扑 压测节点 1 (8核/16G/万兆) HSM SDK 客户端 压测节点 2 (8核/16G/万兆) HSM SDK 客户端 压测节点 3 (8核/16G/万兆) HSM SDK 客户端 万兆交换机 VLAN 隔离 HSM 设备 1 (主节点) 端口 2345/6789 HSM 设备 2 (备节点) 端口 2345/6789 监控/日志服务器 Prometheus + Loki 端口 9090/3100 安全组规则隔离

这个图里,压测节点1~3通过万兆交换机连接到 HSM 设备1和2。HSM 设备1是主节点,2是备节点。右下角有个独立的监控服务器,专门收日志和指标。所有设备都在同一个安全组内,对外只开放必要端口。

我个人建议:如果条件允许,把压测节点和 HSM 设备放在同一个二层网络,减少路由跳数。我在一次跨国压测中就因为多了三层路由,延时从 0.8ms 飙到 3ms,最后排查发现是防火墙策略导致 buffer 太大。

安全组规则

安全组规则不是什么新鲜事,但压力测试时容易忽略一个问题:你既要保证压测流量能自由通过,又要防止外部干扰影响测试结果。因此我推荐以下白名单策略:

  1. 源地址限定:只允许压测机网段的 IP 访问 HSM 设备的服务端口。
  2. 端口限定:HSM SDK 通常使用 TCP 端口(如 2345 用于控制通道,6789 用于数据传输)。其他端口全部关闭。
  3. 协议限定:只放行 TCP,不要开放 ICMP(方便 ping 探测的除外,但压测期间建议关掉,避免响应 ICMP 消耗设备 CPU)。
  4. 出方向规则:压测机可以出外网(用于安装依赖包),但 HSM 设备除了必要的 NTP 和对端同步外,出方向全封。

一个避坑实战经验:我曾经在压测某款国产 HSM 时,发现 TPS 始终上不去。抓包后发现 HSM 设备在握手阶段会主动向压测机发送一个 SYN+ACK 后,再等一个确认,再发送一个“安全协商”包。结果安全组把那个“安全协商”包当成了非法流量丢了。后来我分析报文特征,把这个包的端口和协议显式加进白名单才搞定。如果你遇到类似情况,记得用 tcpdump 抓包看看 HSM 设备实际用了哪些端口和协议。

下面是一个简易的安全组规则示例(参考 AWS 安全组语法):

入站规则(HSM 设备)
- 来源:10.0.1.0/24(压测机子网)
  协议:TCP,端口:2345-2346
- 来源:10.0.1.0/24
  协议:TCP,端口:6789
- 来源:0.0.0.0/0
  协议:UDP,端口:123(NTP,仅限基础同步)

出站规则(HSM 设备)
- 目标:0.0.0.0/0
  协议:UDP,端口:123
- 目标:10.0.1.0/24(将日志推送到监控服务器)
  协议:TCP,端口:3100(Loki)
- 目标:10.0.2.0/24(备节点同步)
  协议:TCP,端口:8443
- 其余全部拒绝

再次强调:安全组规则越细越好。别图省事直接写 0.0.0.0/0 allow all。那不仅影响测试准确性,还容易被隔壁项目组的扫描工具干扰。我在培训时就经历过:测试进行到一半,安全组误封了压测机 IP,机器直接断连,重建环境花了一个小时。