必要 Cookie
免费网络规划工具
同时考虑流量需求与服务器故障。
检查过滤集群的网络容量预算。填入自己的吞吐量测试结果，对比软件限制，并查看部分服务器不可用时的剩余容量。
正常运行与服务器故障
以下预算均已扣除所选预留余量。过滤后出口按保守情况计算，即所有入站流量都需要转发。
横向滚动可查看所有列。
| 场景 | 可用服务器 | 网络预算 | 按实测数据计算的预算 | 评估 |
|---|---|---|---|---|
| 所有服务器可用 | 2 | 160 Gbps | 未提供 | 在所述预算内软件容量未知 |
| 不可用服务器 : 1 | 1 | 80 Gbps | 未提供 | 预算不足软件容量未知 |
显示值经过四舍五入；计算保留完整精度。
本次规划的流量路径
- 未过滤流量入口
- 过滤服务器
- 过滤后出口
模型使用速率相同且独立的入口与出口端口。共享 trunk、单臂架构、反向流量及旁路链路均需单独规划容量。
模型范围有限，计算假设明确
- 两个峰值场景
- 网络需求取输入的 Gbps 峰值与 PPS 场景所需线速中的较大值。这是两个独立规划场景，并非对实际流量记录的重建。
- 路径上的端口容量只计算一次
- 两个 100G 数据端口中，一个入口、一个出口，因此模型按单向 100G 预算计算。四个端口可组成两对，但前提是负载分配有效。
- 先预留余量，再计算服务器数
- 可用容量 = 容量 ×（1 − 预留百分比 / 100）。所需负载除以每台服务器的可用预算，向上取整，再加上允许故障的服务器数。
- 有测量数据时同时使用两项上限
- 在本模型中，实测 Gbps 不会超过端口的物理容量预算。分别按 Gbps 与 Mpps 限制计算服务器数，并采用较大值。不从网卡速率推断软件实测性能。
部署前仍需测试的项目
- 使用实际过滤规则和报文组合，验证 NIC 队列、PCIe 容量、NUMA 绑定、CPU 及内存。
- 测试正常状态和故障后的流量分配。总容量预算不能证明单一流、单一前缀或不均匀哈希分配均可满足限制。
- 检查路由收敛、有状态会话、MTU 和过滤后回送。仅增加备用服务器并不等于已实现自动故障切换。
- 同时遵守上游链路自身的容量限制。本地软件无法恢复已在饱和接入链路上丢失的流量。
- 在依据此计划部署前，应在隔离且获授权的测试环境中验证吞吐量及故障行为。
常见问题
两个 100G 端口是否算作 200G 过滤容量？
不是。模型将一个未过滤入口端口与一个过滤后出口端口配成一对。扣除余量前，这一对端口的单向物理预算为 100G，而软件实际能处理的速率可能更低。
最少服务器数是否认证了 Defense Fabric 的性能？
没有实测数据时，这只是网络容量下限。填入数据后，工具仅按所述假设对比您提供的限制；它不是 Peeryx 基准测试，也不是部署验收结果。
为什么 PPS 输入可能提高 Gbps 需求？
工具按照指定帧大小换算 PPS 场景，并计入以太网开销占用的传输时间。它采用该场景与独立 Gbps 峰值中的较大网络需求。若两者差异较大，请检查帧大小及计数器定义。
计算器会配置冗余吗？
不会。它只计算可用服务器减少后的容量。实际故障切换取决于路由、健康检测、状态处理、物理拓扑和经过测试的恢复流程。
技术参考
将计划与实际部署进行核对
查阅 Defense Fabric 部署指南以了解集成要求；如果瓶颈在接入网络，可评估受保护 Transit 方案。