网安密卷‖万级主机安全解法满分答卷流出

当主机资产数量不断扩大时，探针规模随之增加，这时候服务端往往会超负荷运转，导致：

为了解决这些问题，有的企业不得不选择部署多套环境，这势必带来额外的使用和运维成本、延长响应和处置时间，同时还可能顾此失彼，造成管理上的遗漏。

相较而言，一套环境覆盖全量资产，即用一个服务端管理所有探针，当然是最优选择，然而实现起来却不容易。

有人会问，有这么难吗，提高服务端的硬件配置不就得了？

堆（钞）配（能）置（力）也解决不了问题。

Why?

主机安全产品亦存在同样的C10K问题：

探针规模和服务端硬件配置之间虽然是正相关的，但并不是线性的。

在探针数量没上去时，简单提高服务端硬件配置，可以妥善管理所有探针。

但当探针规模达到万级时，二者关系会达到一个平台期，此时硬件配置再怎么提高，服务端也表示：管不动了。

CPU、存储、网络3个因素，是堆配置也管不动大规模探针的罪魁祸首。

利用CPU 亲和性以及无锁通信虽然可以解决这个问题，但投入产出比太低。

一方面探针规模增加，存储需求成倍增加，很难满足。

仅以文件检测类服务为例，探针数量达到1万时，每周检测总量在 4 T 左右（这通常是企业配置的最大磁盘容量），所有服务相加，数字更为可观。

（注：为便于展示，换算单位为1000）

另一方面存储的读写速度却是一个固定值，很难跟得上。

还是以文件检测任务为例，根据上文的数据，若要在1～2小时内出结果，不考虑任何其他 IO 服务读写要求的前提下，需要4K IOPS （每秒读写次数）的存储介质数量达到5000！

虽然通过磁盘列阵、替换固态硬盘可以提高这个固定值，但存储需求随探针成倍增加，读写速度却无法线性叠加，依旧是木桶短板。当服务端有着复杂的业务查询逻辑时，短板效应会被复杂的 SQL 慢查询显著放大，从而导致管理界面的一些功能页面卡顿，甚至不可用。

首先网络吞吐量大且有峰值。

1万探针规模下，一个文件检测任务要在1小时内检测完，不考虑丢包率和其他内部服务的网络通信的前提下，每秒的网络吞吐量高达153 M/s，只有万兆级别宽带才能hold住这么大规模的吞吐。

靠增强单机硬件性能，如增大网卡 DMA 缓冲区、提高内存、增强CPU 处理能力，在万级的探针规模面前，收效甚微。

其他角度，比如使用 LinuxKit 打造一个更加精简的网络协议栈，或者借助 UIO 直接绕过 Linux 协议栈，直接在用户态处理数据，要么技术还不成熟，要么研发成本过高，都非良策。

其次单机能够承载的 TCP 连接数有极限。

服务端即使增加内存、修改参数，让单机最大并发 TCP 连接数达到10万，这个数值也很快就会被突破。因为：

当 TCP 连接过多，而服务端处理能力不足时，会出现大量处于 wait 状态的 TCP 连接。这不仅导致管理端功能不可用，而且会导致潜在的入侵事件丢失。而入侵事件的丢失，对一款安全产品来说，是不可逾越的红线。

CPU利用率、存储容量和读写速度、网络吞吐量及单机 TCP 连接数限制，是单纯提升服务端硬件配置，即垂直扩展也难以承载大规模探针的根源。

换个思路，水平扩展呢？

“长亭滑板车（Scooter）底座

应运而生！”

滑板车（Scooter）是长亭科技自研的分布式底座，是基于k8s开发的一个企业级容器运行平台，相对于原生k8s，有更好的集群水平扩展能力，具备如下特点：

基于滑板车（Scooter）底座，牧云（CloudWalker）主机安全管理平台可实现上万级探针统一管理，完善的集群服务能力，轻松应对运营商级资产规模。

高可用

牧云（CloudWalker）可确保无人值守场景下业务保持连续不中断，这体现在一些由于人为操作错误、硬件故障等意外中断导致的灾难时，整个服务能自行解决资源、服务问题，起到自动容灾、快速恢复的作用。

弹性伸缩

牧云（CloudWalker）可以针对 CPU 负载进行自动伸缩，从而调整实例或者节点的数量。这对部署在公有云的客户来说非常经济方便，能够节省一大笔服务器费用。

一键部署

整个滑板车（Scooter）底座以及牧云（CloudWalker）的部署，只需一条 shell 命令即可完成。

# 部署滑板车底座./bootstrap.sh
# 部署牧云./submit.sh . -- --set server.ingress=cloudwalker.chaitin.cn

无需人工干预，方便快捷，全程无需甲方运维人员的配合。在某些特殊时期，部署运维的简单还能极大缩短应急周期。