能部署多少台虚拟机？香港EPYC 7713（64核128线程、25M CN2）的容量如何估算？

能部署多少台虚拟机，不能只用“64核128线程”除以每台虚拟机的 vCPU 数量得出。按给定规格估算，若主机配有 256 GiB 内存、存储性能足够，并以 2 vCPU/4 GiB 作为通用型虚拟机模板，在保留宿主机开销和一定超分空间后，可把约 40～50 台作为一个偏稳妥的起始规划区间；低负载的 1 vCPU 小型实例可能达到数十台至近百台，高计算、高内存、数据库或高 I/O 实例则可能只有十几台到二十多台。最终数量取决于 CPU、内存、磁盘和 25 Mbps 网络中的最小可用容量。

这里的“25M CN2”需要先确认产品口径。若 25M 指 25 Mbps 的共享或独享带宽，它代表的是网络吞吐上限，不是每台虚拟机都能获得 25 Mbps，也不能替代 CPU、内存和磁盘容量。虚拟化部署应分别计算可创建数量、正常运行数量和满足峰值请求的数量，三者通常并不相同。

负载画像：先确定虚拟机要承担什么工作

容量估算的第一个变量不是虚拟机数量，而是每台虚拟机的资源画像。不同业务即使拥有相同的 vCPU 和内存，实际消耗也可能相差数倍。

常见虚拟机类型与资源特征

如果业务是网页、API 或后台系统，还需要把请求量转换为资源量。常用的三个变量包括：

• 平均请求率：每秒请求数，也就是 RPS。
• 峰值系数：峰值请求量与平均请求量的比例。
• 单次请求的数据量：包括响应体、上传内容、图片、文件和协议开销。

并发请求数可以用“请求率 × 平均响应时间”进行初步估算。例如平均 100 RPS、平均响应时间为 0.2 秒时，理论上约有 20 个请求处于处理中。但长连接、Keep-Alive、WebSocket、慢请求和客户端连接池会让实际连接数高于这个值，因此连接数不能直接等同于 RPS。

把请求量换算成网络需求

如果平均响应大小为 200,000 字节，业务峰值为 20 RPS，则仅计算响应载荷：

20 × 200,000 × 8 = 32,000,000 bit/s

也就是约 32 Mbps，已经超过 25 Mbps 线路的理论上限，还没有计入 TCP/IP、TLS、重传和其他流量。因此，25 Mbps 线路无法承载这个请求模型的持续峰值。

若将 25 Mbps 中约 20% 留作网络余量，按 20 Mbps 作为规划上限，则平均响应为 200,000 字节时，可支持的理论请求率约为：

20,000,000 ÷（200,000 × 8）= 12.5 RPS

这只是网络层的载荷计算，不代表应用一定能达到 12.5 RPS。数据库查询、应用处理时间、磁盘延迟和连接数都可能提前成为瓶颈。

25 Mbps 持续满载时的理论数据量约为：

• 每秒：25,000,000 ÷ 8 = 3,125,000 字节，约 3.125 MB/s；
• 每天：3.125 MB/s × 86,400 = 270,000 MB，约 270 GB；
• 30天：约 8.1 TB。

这里的 MB 和 GB 按十进制计算，1 MB = 1,000,000 字节，1 GB = 1,000,000,000 字节。实际可用传输量还会受到协议开销、带宽方向、共享策略、计费方式和业务峰值的影响，不能把 8.1 TB 直接理解为可无条件使用的月度流量配额。

资源变量：64核128线程并不等于128个独立核心

CPU容量的计算方式

EPYC 7713 的给定规格为 64 个物理核心、128 个线程。128 线程通常来自 SMT，同一物理核心上的两个硬件线程会共享部分执行资源。虚拟化平台可能把 128 个逻辑 CPU 展示给宿主机，但容量规划不应简单按 128 个完整核心计算。

更适合采用以下关系：

可分配 vCPU 数量 = 物理核心数 × CPU保留比例后的可用量 × 超分比例

例如：

• 物理核心：64；
• 为宿主机、虚拟化调度、监控和突发负载保留 15%；
• 可用于虚拟机的物理核心等效容量：64 × 85% = 54.4；
• 普通应用按 1:2 的 pCPU:vCPU 比例进行超分。

此时可分配的 vCPU 约为：

54.4 × 2 = 108.8

向下取整后约为 108 个 vCPU。这个数字是调度层面的容量预算，不是 108 个持续满载的物理核心。

1:2 并不意味着每台虚拟机都能长期获得双倍的物理计算能力。如果多个虚拟机同时执行编译、压缩、加密、批量计算等任务，CPU ready、steal time 或调度等待会迅速增加。相反，如果虚拟机大部分时间处于空闲状态，较高的超分比例才有实际意义。

对大规格虚拟机，还需要检查 NUMA 拓扑、CPU 绑定和 vCPU 拓扑。一个 16 vCPU 的虚拟机不一定能获得与两个 8 vCPU 虚拟机相同的调度效果，尤其是在内存访问和持续计算负载较重时。容量规划应以压测数据和峰值期间的调度指标为准，而不是只看虚拟机配置页面上的 vCPU 数量。

内存容量往往比CPU更早限制虚拟机数量

内存数量可以按以下关系估算：

可分配内存 = 物理内存 - 宿主机保留 - 虚拟化开销 - 高可用及突发余量

假设主机配有 256 GiB 内存，为宿主机和调度保留 20%，可用于虚拟机的内存约为：

256 × 80% = 204.8 GiB

不考虑磁盘和网络限制时，不同模板的内存上限如下：

这是将 204.8 GiB 完全分配出去后的数学结果，实际生产环境还应留出滚动升级、缓存增长、内核页、监控代理、备份任务和突发请求的空间。如果使用内存气球、内存压缩或交换分区来强行增加数量，表面上的虚拟机数量会上升，但响应时间和 I/O 等待可能明显恶化。

对于数据库和缓存服务，配置给虚拟机的内存也不等于业务真正可用的内存。数据库缓存池、连接池、排序空间、临时表和后台维护任务都可能在高峰时增加占用。因此，数据库类虚拟机建议按照峰值工作集而不是系统启动后的空闲占用来计算。

存储容量要同时看空间、IOPS和延迟

磁盘容量可以用以下方式估算：

可用于虚拟机的存储 = 存储池总容量 - 宿主机及系统占用 - 快照 - 备份临时空间 - 保留空闲空间

例如一个存储池可用容量为 2,000 GB，计划保留 25% 作为性能和增长空间，则可用于虚拟机的空间约为：

2,000 × 75% = 1,500 GB

如果每台虚拟机的实际占用按 50 GB 计算，容量上限约为：

1,500 ÷ 50 = 30台

这里的 50 GB 应包含系统盘、日志、临时文件和预期增长，而不是只看虚拟磁盘的初始分配值。使用精简置备时，逻辑上可以创建更多虚拟磁盘，但实际写入增长、快照合并和备份任务仍会消耗物理空间。精简置备不能替代容量储备。

数据库、日志平台和高并发应用的瓶颈可能先出现在存储延迟上。需要观察：

• 随机读写 IOPS；
• 顺序读写吞吐；
• 平均延迟和高分位延迟；
• I/O队列深度；
• 快照合并和备份期间的延迟变化；
• 存储池剩余空间。

如果磁盘延迟在业务峰值时持续升高，增加 vCPU 通常不能解决问题。更合理的措施是减少高 I/O 虚拟机的并发、拆分存储池、迁移高负载实例或提升存储层性能。

25M CN2的计算边界

如果 25M 指 25 Mbps，网络规划至少要确认以下条件：

• 带宽是入方向、出方向，还是双向共享；
• 25 Mbps 是保证带宽、端口上限还是峰值带宽；
• 多台虚拟机是否共享同一个带宽池；
• 是否存在突发带宽、流量计费或超额限制；
• 25 Mbps 是否覆盖所有流量，包括备份、镜像、迁移和管理流量；
• CN2线路对应的是全部目的地，还是只针对特定运营商或方向。

如果 50 台虚拟机平均每台在峰值时需要 0.5 Mbps，聚合需求为：

50 × 0.5 Mbps = 25 Mbps

这已经没有协议开销和突发余量。若按 20 Mbps 规划上限计算，则 50 台虚拟机平均只能分摊约 0.4 Mbps 的同时峰值带宽，而且不能假设每台都能独立获得这部分带宽。

需要特别区分“虚拟机数量”和“活跃出网数量”。一台没有请求、没有下载、没有备份的虚拟机几乎不占用业务带宽；而一台持续提供图片、文件或视频内容的虚拟机，可能独自占用大部分线路。CN2主要描述网络路径和线路属性，不会增加主机的 CPU、内存或磁盘容量。

面向香港多虚拟机部署，A5数据提供包含EPYC 7713在内的AMD物理服务器，覆盖单路、双路平台及不同内存、存储配置，为网站、API、业务后台和数据库的集中运行提供资源基础。香港产品另有CN2与国际带宽的不同套餐，以及大容量存储系列，可承接计算密集、频繁数据读写和备份归档等不同负载，为业务分层部署与后续容量扩展提供硬件和网络选择。

瓶颈判断：最终数量取四类资源中的最小值

可以用下面的简化模型统一估算：

可部署数量 = min（CPU上限、内存上限、存储空间上限、网络并发上限）

其中：

• CPU上限取决于物理核心、超分比例、峰值利用率和任务类型；
• 内存上限取决于实际工作集、宿主机预留和突发余量；
• 存储上限取决于容量、IOPS、延迟和数据增长；
• 网络上限取决于同时活跃的虚拟机、平均响应大小和 25 Mbps 的实际可用带宽。

一个可复核的容量示例

以下仅用于说明计算方法，不能视为某台服务器的实测承载保证：

• CPU：64个物理核心、128个线程；
• 内存：256 GiB；
• CPU保留：15%；
• 内存保留：20%；
• 通用型虚拟机使用 1:2 的 CPU 超分比例；
• 网络规划上限按 25 Mbps 的 80%，即 20 Mbps；
• 存储容量和 I/O 性能暂时假设不是第一瓶颈；
• 虚拟机并非全部持续满载，业务峰值存在错峰。

按此条件，CPU可用等效容量约为 54 个物理核心，vCPU预算约 108 个；内存可用约 204.8 GiB。不同虚拟机模板的结果如下：

表中的“偏稳妥起始规划”已经为业务波动、镜像操作、监控、备份和部分资源不均衡预留空间，但还没有替代真实业务压测。若虚拟机中有数据库、编译任务或持续文件传输，数量应在此基础上继续下调。

网络可能进一步压低这些数字。例如 50 台 2 vCPU/4 GiB 虚拟机在业务峰值时，每台平均产生 1 RPS、每个响应 200,000 字节，则总带宽为：

50 × 1 × 200,000 × 8 = 80,000,000 bit/s

即 80 Mbps，明显超过 25 Mbps。此时即使 CPU和内存仍有余量，也不能把 50 台都视为满足该请求模型的生产容量。

如果只有 10 台虚拟机同时产生同样的流量，则需求为：

10 × 1 × 200,000 × 8 = 16,000,000 bit/s

即 16 Mbps，在预留后的 20 Mbps 规划上限内，但仍需考虑协议开销和突发。因此，容量估算必须把“同时活跃比例”和“单台业务流量”纳入计算。

容量余量：可创建数量不等于可承诺数量

为不同资源分别设置余量

不能只设置一个笼统的“20%余量”，因为 CPU、内存、网络和磁盘的增长方式不同。

一种可执行的起始规则是：

• CPU：普通混合业务将峰值期间的物理核心使用控制在约 70%～75%以内；
• 内存：宿主机和虚拟机总使用量长期控制在约 75%～80%以内，避免依赖交换；
• 网络：25 Mbps线路按约 17.5～20 Mbps作为常态规划上限；
• 存储容量：达到总池容量的 70%～75%时开始扩容评估；
• 存储性能：以业务压测得到的延迟和队列阈值为准，不只看 IOPS 数字；
• 虚拟机数量：为镜像更新、备份、迁移和临时实例保留未分配资源。

余量的作用不是让服务器长期空闲，而是吸收业务峰值、维护任务和增长误差。如果把所有资源都分配成虚拟机额度，日常监控可能看起来正常，但一旦多个实例同时启动备份、日志轮转或批处理任务，调度和 I/O 延迟会快速放大。

关注增长率而不是只看当前使用量

容量计划应记录至少四种增长变量：

如果当前存储使用量为 900 GB，预留后的容量上限为 1,500 GB，近三个月平均每月增长 100 GB，则理论剩余时间为：

（1,500 - 900）÷ 100 = 6个月

如果增长量存在明显波动，应使用高峰月份或较高分位增长率，而不是只使用简单平均值。备份保留周期、快照数量和数据库归档策略也应纳入增长量，否则计算出的可用时间会偏乐观。

单机容量与高可用容量要分开

一台 64核128线程主机可以按照上述方式估算单机容量，但这不等于具备主机级高可用能力。单机故障、维护、内存故障、存储故障或网络设备故障都可能同时影响该主机上的全部虚拟机。

如果业务需要 N+1 能力，应按“任意一台主机退出后，剩余主机仍能承载业务峰值”的方式规划。只有一台主机时，无法通过多分配一些虚拟机实现 N+1。快照、异地备份和数据副本可以提高恢复能力，但不等同于虚拟机自动切换。

交付验收：把产品规格变成可计算输入

容量估算前，应先确认实际交付参数，而不是只根据销售页面中的简写配置计算。可在授权的宿主机环境中使用只读命令核对 CPU、内存、磁盘和网卡信息：

lscpu | egrep 'Model name|CPU\(s\)|On-line CPU|Core\(s\) per socket|Thread\(s\) per core|NUMA node'
free -h
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
ip -s link

核对时应重点确认：

• CPU是否确实为 64 个物理核心、128 个逻辑线程；
• 虚拟化平台是否隐藏了部分 CPU、内存或 NUMA 信息；
• 内存容量是十进制 GB 还是 GiB，系统可用容量是多少；
• 存储是本地盘、独立存储池还是网络存储；
• 磁盘可用容量与标称容量是否一致；
• 25 Mbps 是单机独享、端口共享还是多实例共享；
• 带宽限制应用在宿主机、虚拟交换机、虚拟机网卡还是上游端口；
• 入方向、出方向和双向总量的计算口径是否一致。

如果只能在虚拟机内部执行命令，lscpu 和 free -h 反映的可能只是该虚拟机看到的资源，不能证明宿主机的物理规格。带宽测试也应使用服务商允许的测试对象和时间窗口，避免直接对生产磁盘执行高强度写入测试。涉及生产数据的 I/O 测试，应提前备份、隔离测试盘，并准备停止测试和恢复业务的方案。

扩容触发点：用持续指标而不是单次峰值决定

建议同时采集宿主机、虚拟化平台和业务层指标。单次尖峰不一定需要扩容，但持续多个业务高峰出现同类问题，通常意味着容量边界已经接近。

阈值不应脱离业务基线单独使用。例如数据库的可接受磁盘延迟可能不同于静态文件服务，API 的 p99 延迟也不能用普通网站的标准替代。实际执行时，可以连续记录 7～14 天的业务高峰数据，再用峰值期间的 p95 或 p99 指标确定阈值。

扩容方向应与瓶颈对应：

• CPU先达到上限：降低 CPU 超分比例、限制高峰任务，或增加计算节点；
• 内存先达到上限：增加物理内存或减少虚拟机密度，不建议依靠交换分区硬撑；
• 25 Mbps先达到上限：优先升级带宽或调整流量架构，增加 vCPU 无法解决网络瓶颈；
• 磁盘延迟先升高：迁移数据库和日志类实例、拆分存储池或升级存储性能；
• 容量满足但需要故障切换：增加第二台或更多主机，并按 N+1 重新计算可承诺容量；
• 业务增长方向不均衡：不要按虚拟机数量平均扩容，而应按 CPU、内存、I/O 和带宽的实际增长曲线扩容。

因此，香港 EPYC 7713 64核128线程主机的虚拟化容量，更适合用“资源画像 + 峰值模型 + 余量 + 监控阈值”的方式计算。若采用 256 GiB 内存、2 vCPU/4 GiB 的通用模板，并且业务流量较轻、存储性能充足，40～50 台可以作为一组条件化的规划参考；若请求响应体较大、数据库比例较高，或者 25 Mbps 线路需要同时承载大量下载、备份和迁移流量，实际数量应以网络或磁盘压力先达到阈值的结果为准。部署后持续记录 CPU争用、内存回收、磁盘延迟、带宽峰值和业务 p95 延迟，并在任一关键指标连续越过阈值前完成扩容，才能把估算容量转化为可执行的资源计划。