虚机密度上升时，香港EPYC服务器虚拟化如何从单机分阶段扩展到集群？

香港业务刚开始运行时，一台配置合理的 EPYC 服务器通常足以承载网站、接口服务、管理后台、轻量数据库和监控等虚拟机。此时直接建设多节点集群，会提前引入共享存储、集群网络、故障仲裁、授权和运维复杂度，投入未必与业务规模匹配。

更稳妥的路径是把扩展拆成几个阶段：先用单机虚拟化建立资源基线，再根据访问量、虚机密度、数据增长和维护要求进行第一次硬件升级；当单机故障影响、维护窗口或资源峰值成为业务风险后，再扩展为两节点或三节点集群。香港 EPYC 服务器的选型重点，不是一次性购买核心数最多的设备，而是让 CPU、内存、NVMe、网络、备份和故障转移能力按照业务增长顺序匹配。

起步阶段：用单台 EPYC 服务器承载第一批虚拟机

单机模式适合什么业务

单机虚拟化适合业务规模尚未稳定、虚机数量有限、可以接受计划维护窗口的场景，例如：

• 企业官网、营销站点和内容管理系统；
• API 服务、后台管理系统和定时任务；
• 测试环境、预发布环境和内部工具；
• 访问量较低的电商前台、预约系统或工单系统；
• 对 RTO 要求不高、可以通过备份恢复的业务。

这里的“适合”并不等于服务器可以长期运行在满负载状态。单机阶段仍然要为突发流量、备份、系统更新和虚机迁移预留资源。如果一台服务器平时已经使用了大部分 CPU、内存和存储性能，那么它只是暂时没有报错，并不代表架构健康。

起步阶段可以用一台单路或双路 EPYC 主机，具体取决于内存容量、PCIe 设备数量和虚机规模。对于一般 Web、API 和管理系统，单路平台往往更容易控制 NUMA 复杂度；只有当业务需要更多内存通道、更多 PCIe 插槽、更多本地 NVMe 或更高的物理核心数量时，才有必要考虑双路平台。

起步配置应关注资源结构

以下是一个用于规划的参考场景，并非固定配置模板：

EPYC 平台的高核心密度适合承载多台虚机，但虚拟机密度上升后，瓶颈可能先出现在内存、存储延迟或网络，而不是 CPU。比如一个网站集群只有 30% 的 CPU 使用率，但数据库随机读延迟持续升高，新增 CPU 核心也不会直接解决问题。

起步阶段应记录以下基线：

• 每台虚机的 vCPU、内存、磁盘容量和业务用途；
• 宿主机 CPU 使用率、负载、内存余量和交换分区活动；
• 存储池已用容量、读写 IOPS、吞吐量和延迟；
• 网卡带宽、丢包、错误包和备份时间；
• 高峰访问量、并发连接数、请求延迟和错误率；
• 备份成功率、恢复耗时以及最近一次恢复演练结果。

这些数据的价值在于区分“业务真的增长了”和“某个服务配置不合理”。例如，单个数据库虚机的连接池过大、应用日志没有轮转、磁盘快照长期保留，都可能造成资源异常，但不一定需要立即扩容。

单机阶段的资源分配原则

一般 Web 和接口服务可以采用适度的 CPU 超分配，例如物理核心与 vCPU 总量保持在约 1:1 至 1:2 的范围内，再根据实际 CPU ready 或 steal time 调整。数据库、编译任务、实时分析和持续高负载服务不应简单套用这一比例。

内存超分配需要更加谨慎。气球驱动、内存合并或交换机制可以在特定平台上缓解短时压力，但不能把实际内存不足当成长期规划方式。单机阶段建议保留约 20% 至 30% 的宿主机内存余量，用于缓存、备份、迁移和突发负载。

存储也要分层管理：

• 宿主机系统盘与虚机数据盘分开；
• 高 I/O 数据库与普通网站虚机尽量分开存储池；
• 快照用于短期变更保护，不替代备份；
• 备份副本不能与生产虚机放在同一组物理磁盘上；
• 容量达到约 70% 至 80% 时，就应开始规划扩容或迁移，而不是等到磁盘完全写满。

增长信号：什么时候单机开始接近边界

访问量增长本身不能直接决定是否扩容。同样的请求量，静态页面、缓存命中较高的 API 和复杂数据库查询，对服务器的消耗可能相差很多。判断升级时，应将访问量、并发、数据量和资源监控结合起来。

需要持续观察的指标

这些阈值是规划参考，不是统一的告警标准。对于延迟敏感的交易或接口服务，CPU 达到 50% 可能就需要关注；对批处理任务而言，CPU 短时间达到 90% 也可能是正常现象。

虚机数量可以作为辅助指标。比如从 8 台增长到 20 台，并不必然需要集群；但如果其中有数据库、消息队列、订单服务、管理后台和多个对外接口，单台宿主机的故障影响面已经明显扩大，就不能只看虚机总数。

用访问量和数据量判断扩展时机

可以建立一个简单的容量记录表，把业务指标与基础设施指标放在同一时间轴上：

表中的访问量只用于说明规划思路。实际扩容仍应以应用响应时间、数据库指标和主机监控为依据。一个每分钟只有几百次请求但包含大量报表查询的系统，可能比高缓存命中的内容站点更早需要升级。

第一次升级：先解决单机的主要瓶颈

第一次升级不一定等于立即购买集群。很多业务在单机阶段还有一次“垂直扩展”机会，即增加内存、优化存储、升级网卡或把高负载虚机迁移到新的 EPYC 主机。

面向虚机密度逐步上升的业务，A5数据提供香港单路及双路AMD EPYC物理服务器，结合不同容量的内存与NVMe存储，为Web、接口、数据库和多任务运行提供分档资源基础。香港产品中的CN2与国际带宽方案可承接不同访问方向的网络需求，大容量存储系列则可用于备份数据和归档文件承载，从单机起步、增加计算节点到分离存储负载，为分阶段扩展提供硬件资源选择。

升级顺序应由瓶颈决定

如果内存不足，优先增加内存，而不是增加 CPU 核心。内存不足会触发交换、缓存抖动和虚机性能下降，增加核心无法消除这些问题。

如果存储延迟过高，应先检查以下项目：

• 是否把数据库、日志和普通网站放在同一存储池；
• 是否存在长期快照或高频备份任务；
• NVMe 是否达到写入耐久度或温度限制；
• 文件系统和虚拟磁盘是否已经接近容量上限；
• 是否需要将高 I/O 业务独立到另一组磁盘。

如果网络达到瓶颈，应区分业务出口、虚机间流量、备份流量和迁移流量。香港机房的带宽方案可能同时涉及端口速率、可用带宽、流量方向和计费方式，不能只按照网卡标称速率估算。1GbE、10GbE 是接口能力，不代表业务在任何时段都能获得同等的可用带宽。

CPU 升级要特别核对平台兼容性。不同 EPYC 代际、主板 BIOS、内存规格和散热设计可能限制处理器替换。如果更换 CPU 需要同时更换主板、内存或散热系统，直接采购一台新的宿主机有时更容易控制停机时间和迁移风险。

单机垂直升级与增加节点的取舍

第一次升级时，不建议把所有虚机平均分配到更大的主机上就结束。应先按业务角色重新分组。例如，将数据库和消息队列放入高性能存储，将测试环境安排在可被暂停的资源池，将对外接口与后台管理系统分开监控。这样后续扩展时，可以只迁移高增长部分，而不必整体重构。

升级后的验收重点

升级完成后，应使用接近生产的负载进行验收，而不是只检查系统是否能够启动：

1. 核对宿主机识别到的物理核心、内存通道、NUMA 节点和 PCIe 设备。
2. 检查虚机迁移、关机启动、快照删除和备份恢复是否正常。
3. 对数据库、日志写入和接口请求分别观察延迟，不只看综合吞吐量。
4. 在高峰模拟或压测期间确认宿主机仍保留可用内存和 CPU 余量。
5. 检查香港机房侧端口速率、IP 配置、带宽方向和流量统计是否与采购条件一致。
6. 记录升级前后的容量基线，方便判断后续增长是否来自业务还是配置变化。

架构扩展：从单机走向两节点或三节点集群

什么时候需要集群

集群的主要价值不是让所有虚机自动变快，而是降低单台宿主机故障和维护对业务的影响。以下情况通常比“虚机数量达到多少台”更能说明集群需求：

• 关键业务不能接受整机维护停机；
• 宿主机故障会同时影响多个收入或生产系统；
• 需要在升级、补丁和硬件更换期间迁移虚机；
• 业务存在明显的峰值错峰需求，需要在节点间调度；
• 备份恢复时间已无法满足业务要求；
• 需要为数据库、API、缓存和后台服务保留不同的故障处理路径。

两节点可以用于基础的迁移和有限冗余，但必须认真处理仲裁问题。若两台主机之间通信中断，系统需要判断是某台主机故障，还是网络分区。没有可靠的 quorum 或 witness 时，可能出现双主、资源争抢或集群停止调度。

如果业务要求较明确的高可用能力，三台计算节点通常更容易规划仲裁和 N+1 容量。第三节点不只是“多买一台服务器”，还应具备与其他节点相近的 CPU 指令集、内存能力、网络带宽和存储性能，否则故障转移后可能出现虚机能启动但性能不足的问题。

三种常见的集群扩展路径

KVM、Proxmox VE、Hyper-V 等虚拟化平台都可以承担不同形式的虚机管理，但不能只依据平台名称判断集群能力。实际交付时，需要确认虚机磁盘格式、在线迁移条件、共享存储支持、网络桥接、备份接口、故障转移机制和授权模式。

按 N+1 方式计算集群容量

集群不能把所有物理资源都分配给业务。以三台相同的 EPYC 主机为例，每台有 32 个物理核心和 256GB 内存：

• 三台合计为 96 个物理核心和 768GB 内存；
• 按一台节点故障后仍能运行，至少要预留一台节点的容量；
• 剩余两台可提供 64 个物理核心和 512GB 内存；
• 如果再保留约 15% 的运行余量，可用于虚机的内存约为 435GB；
• CPU 则应根据业务峰值和超分配策略确定，不能简单把 64 个物理核心全部换算成可分配 vCPU。

这个例子中的 435GB 只是计算值，实际还要扣除宿主机、缓存、存储服务和监控组件占用。若关键虚机在故障后必须全部保留性能，就应按故障后的两台主机能力进行规划，而不是按三台主机正常运行时的总资源做预算。

对于存储，还要考虑副本和故障重建。比如三节点本地存储采用双副本或三副本时，可用容量不会等于所有磁盘容量相加；节点故障后进行重建还会占用网络和磁盘 I/O。数据池使用率达到约 60% 至 70% 时就开始规划扩容，通常比使用率接近 90% 后再重建更可控。

香港部署中的网络和故障域

香港本地部署时，集群节点可以位于同一机柜、同一机房区域或不同供电域。不同位置带来的保护范围不同：

• 同机柜：可以降低单台服务器故障影响，但无法应对机柜供电或交换机故障；
• 同机房不同机柜：可以进一步分散供电和机柜风险，但仍受机房级事件影响；
• 不同机房或异地备份：可以提高灾难恢复能力，但会引入链路延迟、带宽、数据同步和合规管理问题。

如果业务主要服务香港及周边用户，集群节点之间的内部网络应优先保障低延迟、稳定丢包率和足够的迁移带宽。对外业务带宽、虚机管理网络、存储复制网络和备份网络最好进行逻辑或物理隔离。

例如，要把 500GB 的数据在 2 小时内完成初始备份，按十进制容量计算：

• 500GB × 8 = 4000Gb；
• 2 小时 = 7200 秒；
• 4000Gb ÷ 7200 秒 ≈ 0.556Gbps，也就是约 556Mbps 的理论平均速率；
• 加上协议开销、磁盘波动和其他业务流量，实际链路规划可能需要接近 700Mbps 至 800Mbps 的可用余量。

这里的 500GB 是存储容量，转换后得到的是 Gbps 传输速率，不能把 500GB 直接当成 500Gbps。跨机房备份或复制还应结合峰值业务流量，避免复制任务挤占对外服务带宽。

迁移与退出条件：不要等单机达到满载才切换

从单机迁移到集群，重点不是把虚机一次性搬过去，而是让迁移过程可验证、可回退，并且不把原有的单点风险转移到共享存储或核心交换机上。

进入集群前的迁移顺序

迁移前应先完成业务盘点：

• 标记每台虚机的业务等级、负责人、依赖服务和维护窗口；
• 记录数据库、文件服务、消息队列和定时任务之间的启动顺序；
• 明确 RPO 和 RTO，例如数据最多允许丢失多少分钟、故障后要求多久恢复；
• 确认 IP、DNS、证书、授权绑定和主机名是否依赖原宿主机；
• 确认虚机操作系统、虚拟硬件版本和 CPU 指令集是否适合新集群。

之后分批迁移。测试环境和无状态服务可以先迁移，用于验证网络、存储和监控；数据库、订单服务和文件服务应安排单独窗口，完成备份、复制一致性检查和恢复演练后再切换。

一套较稳妥的迁移流程是：

1. 对原单机和关键虚机做完整备份，并确认备份可以读取。
2. 在新集群建立相同或兼容的虚机资源、网络和存储策略。
3. 先迁移非关键虚机，观察 CPU、内存、网络和存储性能。
4. 对关键虚机进行增量同步或停机复制，记录最后同步时间。
5. 在维护窗口内暂停写入、完成最终同步，再切换业务入口。
6. 检查应用登录、接口请求、数据库一致性、定时任务和日志采集。
7. 保留旧虚机或原存储一段观察期，不要在刚完成切换时立即删除。
8. 如果验证失败，按照预先定义的回退路径切回旧环境，并记录差异。

删除旧虚机、清理快照和释放旧磁盘属于不可逆或影响范围较大的操作。执行前应确认备份保留期、回退时间窗口和业务负责人批准，避免因为过早清理而失去恢复路径。

哪些情况不适合立即建设集群

并非所有业务增长都需要马上进入集群。以下情况可以先继续优化单机或采用双机过渡：

• 主要瓶颈是应用代码、数据库索引或缓存策略；
• 虚机数量少，业务可以接受明确的维护窗口；
• 关键数据已经有独立备份，恢复时间符合要求；
• 业务峰值短暂，且主机仍保留足够资源；
• 团队没有稳定的集群、存储和故障演练能力；
• 集群投入会明显挤压备份、监控和带宽预算。

高可用平台也不会自动解决应用层问题。数据库主从、应用会话、文件锁、任务重复执行和消息消费一致性，都需要应用本身支持。虚机能够在另一台 EPYC 主机上启动，不代表业务可以无感恢复。

进入下一阶段的触发信号

可以把以下信号作为阶段切换依据：

• 单机 CPU 高峰后长期超过约 65%至70%，且优化虚机配额后仍无法降低；
• 宿主机可用内存长期低于 20%，开始出现交换、回收或虚机内存抖动；
• 存储池使用率接近 70%至80%，扩容和备份已经影响业务窗口；
• 数据库或接口延迟与存储 I/O、网络拥塞同时升高；
• 备份任务无法在既定窗口内完成，恢复时间超过业务要求；
• 单台宿主机维护会造成不可接受的停机；
• 关键服务数量增加，整机故障会同时影响多个业务链路；
• 需要在线迁移、节点维护或 N+1 故障承载能力；
• 新增内存、磁盘和网卡后，单机仍无法满足未来约 6至12个月的增长空间；
• 团队已经具备集群监控、备份恢复、故障演练和变更管理能力。

达到这些信号后，可以先从第二台 EPYC 主机和统一网络开始，再根据 RTO、数据量和维护要求决定采用共享存储、本地盘复制，还是计算与存储分离。这样扩展出来的集群既能承接当前虚机密度，也能为后续数据增长留下清晰的迁移和退出路径。