手上有台物理服务器却不知道该怎么分给几个人用——这场景我碰到太多次了。机器买回来或者托管在机房跑单一业务绰绰有余可一旦要同时跑测试环境、预发布环境、几个内部小站全塞进一套系统里迟早出事某人装错一个包另一个人的服务直接起不来某个脚本把 CPU 吃满整台机器跟着卡死。这时候 VPS 架设就成了刚需——把一台物理机切成若干台互相看不见、各自有独立系统盘的虚拟专用服务器谁的系统谁负责出问题只影响自己那一台。这篇东西讲的就是这件事的完整落地过程从一台裸机开始怎么规划资源、怎么选虚拟化路线、怎么用现成平台或者纯命令行把 VPS 一台台开出来、怎么交付给使用者、后面怎么盯住不出事。要说清楚边界这里讲的是在你自己可控的硬件上做虚拟化分片面向的是建站、开发测试、CI 构建机、内部服务、教学实验环境这类用途跟去服务商那儿买一台现成主机是两回事。适合的读者也很明确手上有物理机或托管机、会敲基本 Linux 命令、想把资源切开分给多个人或多种环境用的运维、独立开发者、小团队负责人。完全没碰过 Linux 的也不用急着关页面第二、三章我会把前置条件交代清楚照着做能跑通。1. 先把账算清楚VPS 到底该用什么方式切1.1 从一台机器一件事到一台机器多租户物理服务器最朴素的使用方式就是装一套系统、跑一组服务。这种模式在早期没问题但随着业务变复杂麻烦会集中爆发在三个地方。第一个是依赖冲突A 项目要 Python 3.8B 项目要 3.11同一套系统里来回切换早晚出乱子。第二个是故障扩散一套系统里任何一个进程把内存吃干净OOM Killer 挑谁下手全看运气可能把最关键的服务干掉。第三个是权限边界把 root 给出去谁都不放心不给又干不了活。VPS 的思路本质上是把这三个问题用隔离一次性解决。每台 VPS 有自己的内核态KVM 路线、自己的文件系统、自己的网络栈、自己的 root 账号。使用者在自己那台里怎么折腾都行删库重装都无所谓宿主和其他 VPS 不受影响。我给一个内部团队做过这种改造之前他们的测试环境是一台机器上开五个目录改完之后每个环境一台 VPS重建环境从半天缩短到三分钟方法就是把做好的模板克隆一份。理解这一点很重要因为它决定了后面所有的技术选型都围绕隔离强度和资源开销这两个维度做权衡而不是简单地比谁装得快。1.2 三条虚拟化路线的取舍真要动手绕不开的选择就三种全虚拟化KVM/QEMU 这一类、容器化LXC/LXD 这一类、以及混合方案。很多人一上来就问哪个好这问题没答案得看你要交付什么。路线隔离强度单实例内存开销能否跑异构内核启动速度适合场景全虚拟化 KVM强硬件级隔离约 100–300MB 固定开销能各跑各的内核10–30 秒交付给外部使用者、多系统混跑容器 LXC中共享宿主内核接近 0只算进程内存不能必须同内核1–2 秒内部环境、快速重建、密度优先混合KVM 为主 容器补位按需按需部分能混合大多数真实生产我个人的默认选择是混合对外的、要给 root 的、可能跑不同发行版的一律上 KVM内部 CI 构建机、临时压测环境这种用完就删的用容器更划算一台 64GB 内存的机器用容器能塞三四十个构建节点用 KVM 可能就二十出头。这里有个常被忽略的点容器共享宿主内核意味着宿主内核一升级所有容器跟着受影响某台容器里如果触发了内核 bug理论上可能波及宿主。所以只要这台 VPS 的使用者不完全可控就别图省内存用容器省下的那点内存出事时赔进去的时间远不止。1.3 资源超卖的边界与容量规划买服务器的时候销售会告诉你64 核 128G能开 60 台 VPS这话只能听一半。真实能开多少台取决于你愿意接受多高的超卖比以及使用者的负载特征。先把宿主的开销扣掉。虚拟化平台本身、监控、备份进程、日志加起来预留 2–4GB 内存和 2 个核是稳妥的。剩下 124GB如果每台 VPS 给 4GB账面是 31 台。但内存不能按账面开。看使用者的实际峰值如果是开发测试机P95 内存占用通常只有分配量的 40%–60%这种情况下 1:1.5 的超分是安全的如果是对外提供服务的机器峰值可能贴着上限跑那就老老实实 1:1别超。CPU 相对宽松因为绝大多数时间在等 IO。经验值是 1:3 到 1:4 的 vCPU 超分比前提是你给每台配了合理的 CPU 限额cgroup 或 KVM 的 cpu shares避免某一台把物理核全占满。磁盘是最容易翻车的地方。用了 thin provisioning精简置备之后你给 30 台各分 100GB账面 3TB实际写入可能只有 800GB看起来很美好。但只要有几台同时写满存储池一爆所有 VPS 一起挂。我的做法是留 25% 的富裕空间并且在监控里对存储池使用率设 70% 的告警线到线就停下来处理而不是等它自己撑爆。提示容量规划做完之后把账面数、实际可开数、告警阈值三个数字写进文档。后面加机器、加人的时候这三行字能救你。2. 硬件与系统底座的准备2.1 硬件选型与磁盘布局VPS 宿主对硬件的偏好跟普通业务机不太一样。CPU 核心数比单核主频更重要因为你要切的是核数内存容量直接决定能开几台是最该堆的部件磁盘看的是 IOPS 和随机写性能而不是容量。磁盘这一块我踩过大坑。早期用两块机械盘做 RAID1开了十几台 VPS 之后只要有两台同时在编译代码全盘的 IO 延迟直接冲到几百毫秒所有 VPS 都卡成幻灯片。换成 SSD 之后立刻正常。条件允许的话企业级 SSD 做 RAID10至少四块盘预算紧就两块 NVMe 做 RAID1别用单盘单盘一坏所有 VPS 全没。文件系统层面有两个常见选择LVM-thin 和 ZFS。LVM-thin 成熟、性能损耗小、快照和精简置备都支持缺点是快照多了之后碎片化明显回收空间需要手动 fstrim。ZFS 功能更全压缩、校验、快照、发送接收一应俱全代价是吃内存建议每 TB 配 1GB ARC并且写放大会消耗 SSD 寿命。我的取舍是盘多、内存富余、需要定期异地备份的用 ZFS盘少、内存紧、只追求性能的用 LVM-thin。2.2 系统安装与基础加固宿主系统我一般选 Debian 稳定版或者对应的服务器发行版理由很简单包版本保守不会三天两头给你推大更新跑几年不出幺蛾子。安装时只装最小系统不加桌面环境能少一个包就少一个包。装完第一件事是加固。SSH 改端口、禁密码登录只留密钥、关掉 root 直连这三步是基本功。然后是防火墙默认拒绝所有入站只放行 SSH 和管理端口其余端口等具体的 VPS 建好之后再按需开。内核参数要调几项直接影响多实例下的稳定性# /etc/sysctl.d/99-vps-host.conf # 减少 swap 倾向虚拟化宿主上频繁换页会拖垮所有实例 vm.swappiness 10 # thin provision 场景下脏页回写太激进会造成 IO 尖刺 vm.dirty_ratio 10 vm.dirty_background_ratio 5 # 提高文件句柄上限多实例叠加后很容易打满默认值 fs.file-max 2097152 # ARP 缓存与邻居表桥接网络下实例多时容易溢出 net.ipv4.neigh.default.gc_thresh1 1024 net.ipv4.neigh.default.gc_thresh2 4096 net.ipv4.neigh.default.gc_thresh3 8192vm.swappiness调到 10 不是玄学。宿主一旦开始大量换页磁盘队列会被 swap 写满所有 VPS 的 IO 一起遭殃这个连锁反应比单机场景严重得多。至于脏页比例默认的 20% 在几十个实例并发写的时候会攒出一大波回写表现为周期性的卡顿调到 10/5 之后曲线明显平滑。2.3 网络规划网桥、独立 IP 与内网段网络是新手最容易卡住的地方。核心概念只有一个VPS 要对外提供服务就得有一个能路由到它的地址。两种做法。第一种是桥接。宿主建一个网桥vmbr0把物理网卡挂上去VPS 的虚拟网卡也挂上去这样 VPS 就像接在同一台交换机上直接拿独立 IP。这种方案配置最直观性能也好缺点是需要你有多个可用 IP并且机房那边允许你这么用有些托管商对 MAC 地址有绑定策略需要提前报备。第二种是 NAT。宿主自己拿一个公网 IP内部给 VPS 分配 10.x 或 192.168.x 的私网地址对外服务靠端口映射。IP 不够的时候只能这么干代价是映射表要维护好端口冲突得自己协调。# /etc/network/interfaces 片段Debian 系桥接方案 auto vmbr0 iface vmbr0 inet static address 203.0.113.10/24 gateway 203.0.113.1 bridge-ports eno1 bridge-stp off bridge-fd 0这里有个细节值得说bridge-fd 0是关掉转发延迟不写的话新接入的虚拟网卡会有几秒钟学不到 MAC表现为 VPS 起来之后网络要等一会儿才通排查起来很费时间。另外桥接模式下宿主自己的防火墙规则要留意FORWARD 链默认策略如果是 DROPVPS 的流量会被悄悄拦掉日志里还看不到明显报错这个坑我当年找了一整晚。3. 用现成平台落地从裸机到可交付 VPS3.1 平台安装与初始配置如果你不想从零拼命令行用一套开源的虚拟化管理平台是最省事的路径。这类平台把 KVM、存储、网络、Web 管理界面打包好了装完就能在浏览器里点着开机器。我常用的那套基于 Debian安装过程就是写盘、启动、按向导走。安装时唯一需要动脑的是磁盘配置。默认会建议用整盘做 LVM-thin 或者 ZFS如果机器有多块盘我倾向于系统盘单独一块小 SSD数据盘另外组池这样系统重装不影响已有 VPS。装完之后第一件事是配好存储和网络然后关掉不必要的服务。管理界面默认走 8006 端口务必只对管理网段开放别直接甩在公网上——这类界面的登录入口是自动化扫描的重点目标暴露出去等于给自己找事。3.2 存储池与模板制作这一步是效率的分水岭。手工装一台 VPS 要十几分钟做完模板之后克隆一台只要二十秒差别就在这儿。做法是拿一个官方的 cloud image各发行版都提供预装好的 qcow2 镜像导入成模板然后用 cloud-init 注入初始化配置。以 Debian 系的镜像为例# 下载并导入 cloud image 作为模板 wget https://cloud.example.org/debian-12-genericcloud-amd64.qcow2 qm create 9000 --name tpl-debian12 --memory 2048 --cores 2 \ --net0 virtio,bridgevmbr0 qm importdisk 9000 debian-12-genericcloud-amd64.qcow2 local-lvm qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0 qm set 9000 --ide2 local-lvm:cloudinit qm set 9000 --boot c --bootdisk scsi0 qm set 9000 --serial0 socket --vga serial0 qm template 9000几个参数值得解释。--scsihw virtio-scsi-pci配合scsi0用的是 virtio 半虚拟化驱动磁盘 IO 性能比默认的 IDE 模拟高出数倍这是必选项不是可选项。--serial0 socket --vga serial0是让控制台走串口好处是你可以在 Web 界面里直接看到启动日志机器网络没配通的时候这是唯一的救命通道。--ide2 ...cloudinit挂载的是 cloud-init 的配置盘后面所有初始化动作都靠它。3.3 创建第一台 VPS 与自动初始化模板有了克隆一台出来并注入配置qm clone 9000 101 --name vps-dev-01 --full qm set 101 --cores 4 --memory 8192 qm set 101 --ipconfig0 ip203.0.113.21/24,gw203.0.113.1 qm set 101 --ciuser devuser --sshkeys ~/.ssh/id_ed25519.pub qm set 101 --nameserver 203.0.113.2 qm start 101--full表示完整克隆会复制一份独立磁盘不加这个参数是链接克隆省空间但依赖模板模板一删机器就废。生产环境我一律用完整克隆磁盘空间换确定性值。--ipconfig0把 IP 直接写进 cloud-init机器首次启动就自动配好网络不需要进控制台手敲。--ciuser和--sshkeys同理开出来就能用密钥登录密码登录压根不用开。整个过程从敲命令到能 SSH 进去实测 25 秒左右。给使用者交付的时候我把这套命令包成一个脚本参数化机器名、核数、内存、IP交给同事自己跑省掉来回沟通。3.4 快照、备份与克隆的正确用法这三样经常被混为一谈实际上定位完全不同。快照是某个时间点的磁盘状态回滚极快但它跟原盘存在同一存储上原盘挂了快照一起没。快照只适合我要改个配置改坏了想退回去这种短周期场景改完确认没问题就该删掉留着会持续占用空间并拖慢 IO。备份是独立的一份数据应该落到另一块盘甚至另一台机器上。备份频率按数据重要程度定我一般给使用者提供每日增量、每周全量两档保留两周。备份一定要定期做恢复演练只备不验等于没备这话听起来老套但真到用的时候发现备份文件损坏的例子我见过不止一次。克隆是纵向扩展的手段一台机器调好了要十台一样的克隆最快。但克隆完记得改主机名、改 IP、重新生成 SSH host key否则十台机器共用一个 host key连接时客户端会一直报冲突警告使用者也分不清自己在哪台机器上。4. 纯命令行路线手工拼一套出来4.1 组件安装与网桥配置不想装整套平台或者要在已有的系统里加虚拟化能力那就自己拼。核心组件就四个QEMU模拟硬件、KVM内核加速模块、libvirt管理接口、cloud-init初始化。# Debian/Ubuntu 系 apt install -y qemu-system-x86 qemu-utils libvirt-daemon-system \ libvirt-clients bridge-utils virtinst cloud-image-utils systemctl enable --now libvirtd # 验证 KVM 加速是否可用输出非空才算成功 kvm-ok || lsmod | grep kvmkvm-ok那一步别跳过。如果宿主是嵌套在别的虚拟机里跑或者 BIOS 里没开虚拟化扩展KVM 模块加载不上QEMU 会退化成纯软件模拟性能差一到两个数量级表现为 VPS 慢得不像话但看不出任何报错。这种问题排查起来特别费劲装完就验证一下最省事。网桥配置在第二章已经写过这里补一个常被漏掉的点宿主的br0拿到 IP 之后物理网卡eno1本身不应该再配 IP否则会出现两个地址在同一广播域里打架表现为间歇性丢包ping 一会儿通一会儿不通。4.2 virt-install 参数逐项拆解virt-install是命令行创建虚拟机的核心工具参数多但逻辑清晰理解几个关键的就行。virt-install \ --name vps-app-01 \ --vcpus 4,sockets1,cores4,threads1 \ --memory 8192 \ --disk path/var/lib/libvirt/images/vps-app-01.qcow2,size100,formatqcow2,busvirtio,cachenone,discardunmap \ --network bridgevmbr0,modelvirtio \ --os-variant debian12 \ --cloud-init user-data/root/ci/vps-app-01.yaml \ --graphics none \ --console pty,target_typeserial \ --import--vcpus 4,sockets1,cores4,threads1这个写法是明确告诉客户机拓扑结构。有些软件尤其是按 socket 授权或者按 NUMA 优化的会因为拓扑不对而发挥不出性能显式写死比让系统自己猜稳。磁盘参数里的cachenone和discardunmap是两个关键。cachenone让 IO 绕过宿主页缓存直通磁盘多实例场景下能避免宿主的缓存被反复冲刷整体吞吐更好。discardunmap打开 TRIM 透传SSD 上长时间运行不做这个设置删除文件后空间不会真正回收写性能会逐渐下降。--os-variant别乱填它决定的是时钟源和驱动优化策略。填错了轻则性能打折重则客户机时钟漂移表现为日志时间戳乱跳、定时任务不准。填之前用osinfo-query os查一下准确的标识。4.3 一份可复用的创建脚本把上面的东西整理成脚本参数化之后交给团队用是我觉得最值的一步投入。#!/usr/bin/env bash set -euo pipefail NAME${1:?用法: ./mkvps.sh 名称 核数 内存MB 磁盘GB IP/掩码} VCPU${2}; MEM${3}; DISK${4}; IPADDR${5} IMAGE/var/lib/libvirt/images/tpl-debian12.qcow2 POOL/var/lib/libvirt/images # 从模板复制一份独立磁盘用 cp --reflink 在支持的文件系统上是秒级的 cp --reflinkauto ${IMAGE} ${POOL}/${NAME}.qcow2 qemu-img resize ${POOL}/${NAME}.qcow2 ${DISK}G cat /tmp/${NAME}-user-data.yaml EOF #cloud-config hostname: ${NAME} users: - name: appuser sudo: ALL(ALL) NOPASSWD:ALL ssh_authorized_keys: - $(cat /root/.ssh/id_ed25519.pub) package_update: false runcmd: - [ systemctl, enable, --now, qemu-guest-agent ] EOF virt-install --name ${NAME} --vcpus ${VCPU} --memory ${MEM} \ --disk path${POOL}/${NAME}.qcow2,busvirtio,cachenone,discardunmap \ --network bridgevmbr0,modelvirtio \ --os-variant debian12 --graphics none --import \ --cloud-init user-data/tmp/${NAME}-user-data.yaml \ --noautoconsole echo ${NAME} 已创建IP 待客户机内配置为 ${IPADDR}脚本里cp --reflinkauto这个细节值得一提在支持 CoW 的文件系统比如 XFS 开了 reflink、Btrfs、ZFS上复制模板几乎是瞬间完成的不占额外空间比qemu-img convert快几十倍。在不支持的文件系统上它会自动退化成普通复制不影响正确性。qemu-guest-agent也建议装上。它能让宿主知道客户机的真实 IP、文件系统使用率做优雅关机而不是硬断电。没装这个的话关机只能靠 ACPI 信号客户机不响应就只能强杀久而久之文件系统容易出问题。5. 交付前的验收与长期运维5.1 性能基线测试与交付检查清单机器开出来不等于能交付。我习惯跑一遍基线测试留个数据存档后面出问题时有对照。CPU 用sysbench cpu run看单核和多核分数磁盘用fio做随机读写重点看 4K 随机写的 IOPS 和延迟网络用iperf3测宿主到客户机的带宽桥接模式下应该接近物理网卡线速如果只有一半甚至更低多半是网桥配置或者中断绑核有问题。# 客户机内执行4K 随机写基线 fio --namerandwrite --ioenginelibaio --iodepth32 \ --rwrandwrite --bs4k --direct1 --size1G \ --numjobs4 --runtime60 --group_reporting交付前的检查清单我固定这么几项检查项标准检查方法SSH 密钥登录可用密码登录已禁本地ssh -i试连主机名与 host key唯一未与模板重复hostnamectl、ssh-keygen -lf时间同步与标准源偏差 1 秒timedatectl status磁盘空间根分区使用率 20%df -hguest agent运行中systemctl status qemu-guest-agent快照/备份策略已挂到备份任务平台侧确认资源限额CPU/内存上限已设平台侧确认5.2 监控、告警与资源回收宿主层面的监控必须自己搭起来别指望使用者反馈。等使用者说我这台很卡的时候通常已经卡了很久了。我最小的一套组合是每台 VPS 装 node_exporter宿主也装数据进时序库面板上看四个核心指标——宿主 CPU 使用率、内存可用量、存储池使用率、每台的磁盘延迟。告警线按经验设存储池 70%、宿主内存可用低于 15%、单台磁盘延迟超过 50ms 持续五分钟。资源回收是个容易被忽略的活。团队里总有人开了机器用完不关半年下来能攒出一堆僵尸实例。我的做法是给每台机器打标签记录创建人、用途、到期时间每月跑一次清单到期前一周发提醒没续期的自动关机保留一周再删。这个流程推行下去之后存储池的使用率从 85% 降到了 50% 左右等于凭空多出一批容量。5.3 多使用者隔离与权限边界只要 VPS 是给别人用的权限就得设计。平台层面我给每个使用者建独立账号只授权到自己名下的那些机器别给全局管理员。宿主的 root 密码只有两个人知道这是底线。网络层面如果不同使用者的机器之间不该互通就在网桥上做隔离或者干脆给他们分到不同的内网段用防火墙规则隔开。这一点在给外部客户交付时尤其重要客户 A 的机器能扫到客户 B 的端口这在合规上是有问题的。还有一条经验给使用者开通机器的时候顺手把默认的 SSH 端口改掉、装上基础的入侵检测和日志审计。不是不信任使用者而是他们的机器一旦被攻破攻击者可能拿它当跳板往宿主和其他机器上打宿主的安全边界会被从内部撕开。KVM 的隔离很强但前提是宿主自己不敞开大门。6. 踩坑记录与常见问题排查6.1 典型故障速查表这些年攒下来的问题绝大多数都集中在几个固定位置。整理成表出问题时先对号入座能省掉大量瞎试的时间。现象最可能原因排查动作处理方式VPS 起不来控制台无输出引导顺序错或磁盘未挂对检查 boot 顺序、scsi0 是否存在修正 bootdisk 设置网络不通但宿主正常FORWARD 链默认 DROP / 网桥未起iptables -L FORWARD -n -v、brctl show放行转发或修正网桥网络通但时断时续物理网卡与网桥同时配了 IP检查 interfaces 配置移除物理网卡 IP磁盘写入极慢未用 virtio 驱动 / cache 模式不当lspci看驱动、查磁盘参数换 virtio cachenone客户机时间漂移os-variant 填错或时钟源不对客户机内chronyc tracking改时钟源为 kvm-clock存储池突然写满thin 超分过度查各盘实际占用扩容或迁移设 70% 告警SSH 连接报 host key 冲突克隆未重新生成 host key比对指纹客户机内重新生成关机卡住不响应未装 guest agentsystemctl status检查安装并启用 agent6.2 几条用时间换来的经验第一条是关于快照的。我见过有人把快照当备份用机器跑了半年攒了二十几个快照某天存储池满了所有机器一起挂因为快照链太长连删都删不动。快照是临时工具不是数据保险这个认知必须在团队里统一。第二条是关于 IP 规划的。一开始觉得 IP 够用随便分配等到要扩机器的时候发现地址段碎得没法整理。我的建议是哪怕现在只有五台机器也按用途划段开发段、测试段、生产段分开每段留足余量并写进文档。改 IP 比一开始就规划好要麻烦十倍。第三条是关于模板的。模板做完之后一定要在一个干净环境里完整跑一遍从克隆、启动、注入配置到能登录、能联网、能装包全流程走通再拿去用。我吃过一次亏模板里残留了旧机器的 cloud-init 状态克隆出来的机器全都用了同一个 IP撞了地址十几台一起断网排查的时候先怀疑网络再怀疑路由最后才发现是模板的问题。第四条也是最实在的一条先把一台机器完整跑顺再考虑批量。VPS 架设这事看着是开很多台实际上难点全在第一台——网络通不通、初始化对不对、性能达不达标这些问题在第一台上暴露出来成本最低。等二十台一起开出来再发现问题返工的工作量是指数级增长的。我现在的习惯是每加一种新配置都先开一台灰度跑一周确认没问题再推广慢一点但省心。
手上有台物理服务器却不知道该怎么分给几个人用——这场景我碰到太多次了。机器买回来或者托管在机房跑单一业务绰绰有余可一旦要同时跑测试环境、预发布环境、几个内部小站全塞进一套系统里迟早出事某人装错一个包另一个人的服务直接起不来某个脚本把 CPU 吃满整台机器跟着卡死。这时候 VPS 架设就成了刚需——把一台物理机切成若干台互相看不见、各自有独立系统盘的虚拟专用服务器谁的系统谁负责出问题只影响自己那一台。这篇东西讲的就是这件事的完整落地过程从一台裸机开始怎么规划资源、怎么选虚拟化路线、怎么用现成平台或者纯命令行把 VPS 一台台开出来、怎么交付给使用者、后面怎么盯住不出事。要说清楚边界这里讲的是在你自己可控的硬件上做虚拟化分片面向的是建站、开发测试、CI 构建机、内部服务、教学实验环境这类用途跟去服务商那儿买一台现成主机是两回事。适合的读者也很明确手上有物理机或托管机、会敲基本 Linux 命令、想把资源切开分给多个人或多种环境用的运维、独立开发者、小团队负责人。完全没碰过 Linux 的也不用急着关页面第二、三章我会把前置条件交代清楚照着做能跑通。1. 先把账算清楚VPS 到底该用什么方式切1.1 从一台机器一件事到一台机器多租户物理服务器最朴素的使用方式就是装一套系统、跑一组服务。这种模式在早期没问题但随着业务变复杂麻烦会集中爆发在三个地方。第一个是依赖冲突A 项目要 Python 3.8B 项目要 3.11同一套系统里来回切换早晚出乱子。第二个是故障扩散一套系统里任何一个进程把内存吃干净OOM Killer 挑谁下手全看运气可能把最关键的服务干掉。第三个是权限边界把 root 给出去谁都不放心不给又干不了活。VPS 的思路本质上是把这三个问题用隔离一次性解决。每台 VPS 有自己的内核态KVM 路线、自己的文件系统、自己的网络栈、自己的 root 账号。使用者在自己那台里怎么折腾都行删库重装都无所谓宿主和其他 VPS 不受影响。我给一个内部团队做过这种改造之前他们的测试环境是一台机器上开五个目录改完之后每个环境一台 VPS重建环境从半天缩短到三分钟方法就是把做好的模板克隆一份。理解这一点很重要因为它决定了后面所有的技术选型都围绕隔离强度和资源开销这两个维度做权衡而不是简单地比谁装得快。1.2 三条虚拟化路线的取舍真要动手绕不开的选择就三种全虚拟化KVM/QEMU 这一类、容器化LXC/LXD 这一类、以及混合方案。很多人一上来就问哪个好这问题没答案得看你要交付什么。路线隔离强度单实例内存开销能否跑异构内核启动速度适合场景全虚拟化 KVM强硬件级隔离约 100–300MB 固定开销能各跑各的内核10–30 秒交付给外部使用者、多系统混跑容器 LXC中共享宿主内核接近 0只算进程内存不能必须同内核1–2 秒内部环境、快速重建、密度优先混合KVM 为主 容器补位按需按需部分能混合大多数真实生产我个人的默认选择是混合对外的、要给 root 的、可能跑不同发行版的一律上 KVM内部 CI 构建机、临时压测环境这种用完就删的用容器更划算一台 64GB 内存的机器用容器能塞三四十个构建节点用 KVM 可能就二十出头。这里有个常被忽略的点容器共享宿主内核意味着宿主内核一升级所有容器跟着受影响某台容器里如果触发了内核 bug理论上可能波及宿主。所以只要这台 VPS 的使用者不完全可控就别图省内存用容器省下的那点内存出事时赔进去的时间远不止。1.3 资源超卖的边界与容量规划买服务器的时候销售会告诉你64 核 128G能开 60 台 VPS这话只能听一半。真实能开多少台取决于你愿意接受多高的超卖比以及使用者的负载特征。先把宿主的开销扣掉。虚拟化平台本身、监控、备份进程、日志加起来预留 2–4GB 内存和 2 个核是稳妥的。剩下 124GB如果每台 VPS 给 4GB账面是 31 台。但内存不能按账面开。看使用者的实际峰值如果是开发测试机P95 内存占用通常只有分配量的 40%–60%这种情况下 1:1.5 的超分是安全的如果是对外提供服务的机器峰值可能贴着上限跑那就老老实实 1:1别超。CPU 相对宽松因为绝大多数时间在等 IO。经验值是 1:3 到 1:4 的 vCPU 超分比前提是你给每台配了合理的 CPU 限额cgroup 或 KVM 的 cpu shares避免某一台把物理核全占满。磁盘是最容易翻车的地方。用了 thin provisioning精简置备之后你给 30 台各分 100GB账面 3TB实际写入可能只有 800GB看起来很美好。但只要有几台同时写满存储池一爆所有 VPS 一起挂。我的做法是留 25% 的富裕空间并且在监控里对存储池使用率设 70% 的告警线到线就停下来处理而不是等它自己撑爆。提示容量规划做完之后把账面数、实际可开数、告警阈值三个数字写进文档。后面加机器、加人的时候这三行字能救你。2. 硬件与系统底座的准备2.1 硬件选型与磁盘布局VPS 宿主对硬件的偏好跟普通业务机不太一样。CPU 核心数比单核主频更重要因为你要切的是核数内存容量直接决定能开几台是最该堆的部件磁盘看的是 IOPS 和随机写性能而不是容量。磁盘这一块我踩过大坑。早期用两块机械盘做 RAID1开了十几台 VPS 之后只要有两台同时在编译代码全盘的 IO 延迟直接冲到几百毫秒所有 VPS 都卡成幻灯片。换成 SSD 之后立刻正常。条件允许的话企业级 SSD 做 RAID10至少四块盘预算紧就两块 NVMe 做 RAID1别用单盘单盘一坏所有 VPS 全没。文件系统层面有两个常见选择LVM-thin 和 ZFS。LVM-thin 成熟、性能损耗小、快照和精简置备都支持缺点是快照多了之后碎片化明显回收空间需要手动 fstrim。ZFS 功能更全压缩、校验、快照、发送接收一应俱全代价是吃内存建议每 TB 配 1GB ARC并且写放大会消耗 SSD 寿命。我的取舍是盘多、内存富余、需要定期异地备份的用 ZFS盘少、内存紧、只追求性能的用 LVM-thin。2.2 系统安装与基础加固宿主系统我一般选 Debian 稳定版或者对应的服务器发行版理由很简单包版本保守不会三天两头给你推大更新跑几年不出幺蛾子。安装时只装最小系统不加桌面环境能少一个包就少一个包。装完第一件事是加固。SSH 改端口、禁密码登录只留密钥、关掉 root 直连这三步是基本功。然后是防火墙默认拒绝所有入站只放行 SSH 和管理端口其余端口等具体的 VPS 建好之后再按需开。内核参数要调几项直接影响多实例下的稳定性# /etc/sysctl.d/99-vps-host.conf # 减少 swap 倾向虚拟化宿主上频繁换页会拖垮所有实例 vm.swappiness 10 # thin provision 场景下脏页回写太激进会造成 IO 尖刺 vm.dirty_ratio 10 vm.dirty_background_ratio 5 # 提高文件句柄上限多实例叠加后很容易打满默认值 fs.file-max 2097152 # ARP 缓存与邻居表桥接网络下实例多时容易溢出 net.ipv4.neigh.default.gc_thresh1 1024 net.ipv4.neigh.default.gc_thresh2 4096 net.ipv4.neigh.default.gc_thresh3 8192vm.swappiness调到 10 不是玄学。宿主一旦开始大量换页磁盘队列会被 swap 写满所有 VPS 的 IO 一起遭殃这个连锁反应比单机场景严重得多。至于脏页比例默认的 20% 在几十个实例并发写的时候会攒出一大波回写表现为周期性的卡顿调到 10/5 之后曲线明显平滑。2.3 网络规划网桥、独立 IP 与内网段网络是新手最容易卡住的地方。核心概念只有一个VPS 要对外提供服务就得有一个能路由到它的地址。两种做法。第一种是桥接。宿主建一个网桥vmbr0把物理网卡挂上去VPS 的虚拟网卡也挂上去这样 VPS 就像接在同一台交换机上直接拿独立 IP。这种方案配置最直观性能也好缺点是需要你有多个可用 IP并且机房那边允许你这么用有些托管商对 MAC 地址有绑定策略需要提前报备。第二种是 NAT。宿主自己拿一个公网 IP内部给 VPS 分配 10.x 或 192.168.x 的私网地址对外服务靠端口映射。IP 不够的时候只能这么干代价是映射表要维护好端口冲突得自己协调。# /etc/network/interfaces 片段Debian 系桥接方案 auto vmbr0 iface vmbr0 inet static address 203.0.113.10/24 gateway 203.0.113.1 bridge-ports eno1 bridge-stp off bridge-fd 0这里有个细节值得说bridge-fd 0是关掉转发延迟不写的话新接入的虚拟网卡会有几秒钟学不到 MAC表现为 VPS 起来之后网络要等一会儿才通排查起来很费时间。另外桥接模式下宿主自己的防火墙规则要留意FORWARD 链默认策略如果是 DROPVPS 的流量会被悄悄拦掉日志里还看不到明显报错这个坑我当年找了一整晚。3. 用现成平台落地从裸机到可交付 VPS3.1 平台安装与初始配置如果你不想从零拼命令行用一套开源的虚拟化管理平台是最省事的路径。这类平台把 KVM、存储、网络、Web 管理界面打包好了装完就能在浏览器里点着开机器。我常用的那套基于 Debian安装过程就是写盘、启动、按向导走。安装时唯一需要动脑的是磁盘配置。默认会建议用整盘做 LVM-thin 或者 ZFS如果机器有多块盘我倾向于系统盘单独一块小 SSD数据盘另外组池这样系统重装不影响已有 VPS。装完之后第一件事是配好存储和网络然后关掉不必要的服务。管理界面默认走 8006 端口务必只对管理网段开放别直接甩在公网上——这类界面的登录入口是自动化扫描的重点目标暴露出去等于给自己找事。3.2 存储池与模板制作这一步是效率的分水岭。手工装一台 VPS 要十几分钟做完模板之后克隆一台只要二十秒差别就在这儿。做法是拿一个官方的 cloud image各发行版都提供预装好的 qcow2 镜像导入成模板然后用 cloud-init 注入初始化配置。以 Debian 系的镜像为例# 下载并导入 cloud image 作为模板 wget https://cloud.example.org/debian-12-genericcloud-amd64.qcow2 qm create 9000 --name tpl-debian12 --memory 2048 --cores 2 \ --net0 virtio,bridgevmbr0 qm importdisk 9000 debian-12-genericcloud-amd64.qcow2 local-lvm qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0 qm set 9000 --ide2 local-lvm:cloudinit qm set 9000 --boot c --bootdisk scsi0 qm set 9000 --serial0 socket --vga serial0 qm template 9000几个参数值得解释。--scsihw virtio-scsi-pci配合scsi0用的是 virtio 半虚拟化驱动磁盘 IO 性能比默认的 IDE 模拟高出数倍这是必选项不是可选项。--serial0 socket --vga serial0是让控制台走串口好处是你可以在 Web 界面里直接看到启动日志机器网络没配通的时候这是唯一的救命通道。--ide2 ...cloudinit挂载的是 cloud-init 的配置盘后面所有初始化动作都靠它。3.3 创建第一台 VPS 与自动初始化模板有了克隆一台出来并注入配置qm clone 9000 101 --name vps-dev-01 --full qm set 101 --cores 4 --memory 8192 qm set 101 --ipconfig0 ip203.0.113.21/24,gw203.0.113.1 qm set 101 --ciuser devuser --sshkeys ~/.ssh/id_ed25519.pub qm set 101 --nameserver 203.0.113.2 qm start 101--full表示完整克隆会复制一份独立磁盘不加这个参数是链接克隆省空间但依赖模板模板一删机器就废。生产环境我一律用完整克隆磁盘空间换确定性值。--ipconfig0把 IP 直接写进 cloud-init机器首次启动就自动配好网络不需要进控制台手敲。--ciuser和--sshkeys同理开出来就能用密钥登录密码登录压根不用开。整个过程从敲命令到能 SSH 进去实测 25 秒左右。给使用者交付的时候我把这套命令包成一个脚本参数化机器名、核数、内存、IP交给同事自己跑省掉来回沟通。3.4 快照、备份与克隆的正确用法这三样经常被混为一谈实际上定位完全不同。快照是某个时间点的磁盘状态回滚极快但它跟原盘存在同一存储上原盘挂了快照一起没。快照只适合我要改个配置改坏了想退回去这种短周期场景改完确认没问题就该删掉留着会持续占用空间并拖慢 IO。备份是独立的一份数据应该落到另一块盘甚至另一台机器上。备份频率按数据重要程度定我一般给使用者提供每日增量、每周全量两档保留两周。备份一定要定期做恢复演练只备不验等于没备这话听起来老套但真到用的时候发现备份文件损坏的例子我见过不止一次。克隆是纵向扩展的手段一台机器调好了要十台一样的克隆最快。但克隆完记得改主机名、改 IP、重新生成 SSH host key否则十台机器共用一个 host key连接时客户端会一直报冲突警告使用者也分不清自己在哪台机器上。4. 纯命令行路线手工拼一套出来4.1 组件安装与网桥配置不想装整套平台或者要在已有的系统里加虚拟化能力那就自己拼。核心组件就四个QEMU模拟硬件、KVM内核加速模块、libvirt管理接口、cloud-init初始化。# Debian/Ubuntu 系 apt install -y qemu-system-x86 qemu-utils libvirt-daemon-system \ libvirt-clients bridge-utils virtinst cloud-image-utils systemctl enable --now libvirtd # 验证 KVM 加速是否可用输出非空才算成功 kvm-ok || lsmod | grep kvmkvm-ok那一步别跳过。如果宿主是嵌套在别的虚拟机里跑或者 BIOS 里没开虚拟化扩展KVM 模块加载不上QEMU 会退化成纯软件模拟性能差一到两个数量级表现为 VPS 慢得不像话但看不出任何报错。这种问题排查起来特别费劲装完就验证一下最省事。网桥配置在第二章已经写过这里补一个常被漏掉的点宿主的br0拿到 IP 之后物理网卡eno1本身不应该再配 IP否则会出现两个地址在同一广播域里打架表现为间歇性丢包ping 一会儿通一会儿不通。4.2 virt-install 参数逐项拆解virt-install是命令行创建虚拟机的核心工具参数多但逻辑清晰理解几个关键的就行。virt-install \ --name vps-app-01 \ --vcpus 4,sockets1,cores4,threads1 \ --memory 8192 \ --disk path/var/lib/libvirt/images/vps-app-01.qcow2,size100,formatqcow2,busvirtio,cachenone,discardunmap \ --network bridgevmbr0,modelvirtio \ --os-variant debian12 \ --cloud-init user-data/root/ci/vps-app-01.yaml \ --graphics none \ --console pty,target_typeserial \ --import--vcpus 4,sockets1,cores4,threads1这个写法是明确告诉客户机拓扑结构。有些软件尤其是按 socket 授权或者按 NUMA 优化的会因为拓扑不对而发挥不出性能显式写死比让系统自己猜稳。磁盘参数里的cachenone和discardunmap是两个关键。cachenone让 IO 绕过宿主页缓存直通磁盘多实例场景下能避免宿主的缓存被反复冲刷整体吞吐更好。discardunmap打开 TRIM 透传SSD 上长时间运行不做这个设置删除文件后空间不会真正回收写性能会逐渐下降。--os-variant别乱填它决定的是时钟源和驱动优化策略。填错了轻则性能打折重则客户机时钟漂移表现为日志时间戳乱跳、定时任务不准。填之前用osinfo-query os查一下准确的标识。4.3 一份可复用的创建脚本把上面的东西整理成脚本参数化之后交给团队用是我觉得最值的一步投入。#!/usr/bin/env bash set -euo pipefail NAME${1:?用法: ./mkvps.sh 名称 核数 内存MB 磁盘GB IP/掩码} VCPU${2}; MEM${3}; DISK${4}; IPADDR${5} IMAGE/var/lib/libvirt/images/tpl-debian12.qcow2 POOL/var/lib/libvirt/images # 从模板复制一份独立磁盘用 cp --reflink 在支持的文件系统上是秒级的 cp --reflinkauto ${IMAGE} ${POOL}/${NAME}.qcow2 qemu-img resize ${POOL}/${NAME}.qcow2 ${DISK}G cat /tmp/${NAME}-user-data.yaml EOF #cloud-config hostname: ${NAME} users: - name: appuser sudo: ALL(ALL) NOPASSWD:ALL ssh_authorized_keys: - $(cat /root/.ssh/id_ed25519.pub) package_update: false runcmd: - [ systemctl, enable, --now, qemu-guest-agent ] EOF virt-install --name ${NAME} --vcpus ${VCPU} --memory ${MEM} \ --disk path${POOL}/${NAME}.qcow2,busvirtio,cachenone,discardunmap \ --network bridgevmbr0,modelvirtio \ --os-variant debian12 --graphics none --import \ --cloud-init user-data/tmp/${NAME}-user-data.yaml \ --noautoconsole echo ${NAME} 已创建IP 待客户机内配置为 ${IPADDR}脚本里cp --reflinkauto这个细节值得一提在支持 CoW 的文件系统比如 XFS 开了 reflink、Btrfs、ZFS上复制模板几乎是瞬间完成的不占额外空间比qemu-img convert快几十倍。在不支持的文件系统上它会自动退化成普通复制不影响正确性。qemu-guest-agent也建议装上。它能让宿主知道客户机的真实 IP、文件系统使用率做优雅关机而不是硬断电。没装这个的话关机只能靠 ACPI 信号客户机不响应就只能强杀久而久之文件系统容易出问题。5. 交付前的验收与长期运维5.1 性能基线测试与交付检查清单机器开出来不等于能交付。我习惯跑一遍基线测试留个数据存档后面出问题时有对照。CPU 用sysbench cpu run看单核和多核分数磁盘用fio做随机读写重点看 4K 随机写的 IOPS 和延迟网络用iperf3测宿主到客户机的带宽桥接模式下应该接近物理网卡线速如果只有一半甚至更低多半是网桥配置或者中断绑核有问题。# 客户机内执行4K 随机写基线 fio --namerandwrite --ioenginelibaio --iodepth32 \ --rwrandwrite --bs4k --direct1 --size1G \ --numjobs4 --runtime60 --group_reporting交付前的检查清单我固定这么几项检查项标准检查方法SSH 密钥登录可用密码登录已禁本地ssh -i试连主机名与 host key唯一未与模板重复hostnamectl、ssh-keygen -lf时间同步与标准源偏差 1 秒timedatectl status磁盘空间根分区使用率 20%df -hguest agent运行中systemctl status qemu-guest-agent快照/备份策略已挂到备份任务平台侧确认资源限额CPU/内存上限已设平台侧确认5.2 监控、告警与资源回收宿主层面的监控必须自己搭起来别指望使用者反馈。等使用者说我这台很卡的时候通常已经卡了很久了。我最小的一套组合是每台 VPS 装 node_exporter宿主也装数据进时序库面板上看四个核心指标——宿主 CPU 使用率、内存可用量、存储池使用率、每台的磁盘延迟。告警线按经验设存储池 70%、宿主内存可用低于 15%、单台磁盘延迟超过 50ms 持续五分钟。资源回收是个容易被忽略的活。团队里总有人开了机器用完不关半年下来能攒出一堆僵尸实例。我的做法是给每台机器打标签记录创建人、用途、到期时间每月跑一次清单到期前一周发提醒没续期的自动关机保留一周再删。这个流程推行下去之后存储池的使用率从 85% 降到了 50% 左右等于凭空多出一批容量。5.3 多使用者隔离与权限边界只要 VPS 是给别人用的权限就得设计。平台层面我给每个使用者建独立账号只授权到自己名下的那些机器别给全局管理员。宿主的 root 密码只有两个人知道这是底线。网络层面如果不同使用者的机器之间不该互通就在网桥上做隔离或者干脆给他们分到不同的内网段用防火墙规则隔开。这一点在给外部客户交付时尤其重要客户 A 的机器能扫到客户 B 的端口这在合规上是有问题的。还有一条经验给使用者开通机器的时候顺手把默认的 SSH 端口改掉、装上基础的入侵检测和日志审计。不是不信任使用者而是他们的机器一旦被攻破攻击者可能拿它当跳板往宿主和其他机器上打宿主的安全边界会被从内部撕开。KVM 的隔离很强但前提是宿主自己不敞开大门。6. 踩坑记录与常见问题排查6.1 典型故障速查表这些年攒下来的问题绝大多数都集中在几个固定位置。整理成表出问题时先对号入座能省掉大量瞎试的时间。现象最可能原因排查动作处理方式VPS 起不来控制台无输出引导顺序错或磁盘未挂对检查 boot 顺序、scsi0 是否存在修正 bootdisk 设置网络不通但宿主正常FORWARD 链默认 DROP / 网桥未起iptables -L FORWARD -n -v、brctl show放行转发或修正网桥网络通但时断时续物理网卡与网桥同时配了 IP检查 interfaces 配置移除物理网卡 IP磁盘写入极慢未用 virtio 驱动 / cache 模式不当lspci看驱动、查磁盘参数换 virtio cachenone客户机时间漂移os-variant 填错或时钟源不对客户机内chronyc tracking改时钟源为 kvm-clock存储池突然写满thin 超分过度查各盘实际占用扩容或迁移设 70% 告警SSH 连接报 host key 冲突克隆未重新生成 host key比对指纹客户机内重新生成关机卡住不响应未装 guest agentsystemctl status检查安装并启用 agent6.2 几条用时间换来的经验第一条是关于快照的。我见过有人把快照当备份用机器跑了半年攒了二十几个快照某天存储池满了所有机器一起挂因为快照链太长连删都删不动。快照是临时工具不是数据保险这个认知必须在团队里统一。第二条是关于 IP 规划的。一开始觉得 IP 够用随便分配等到要扩机器的时候发现地址段碎得没法整理。我的建议是哪怕现在只有五台机器也按用途划段开发段、测试段、生产段分开每段留足余量并写进文档。改 IP 比一开始就规划好要麻烦十倍。第三条是关于模板的。模板做完之后一定要在一个干净环境里完整跑一遍从克隆、启动、注入配置到能登录、能联网、能装包全流程走通再拿去用。我吃过一次亏模板里残留了旧机器的 cloud-init 状态克隆出来的机器全都用了同一个 IP撞了地址十几台一起断网排查的时候先怀疑网络再怀疑路由最后才发现是模板的问题。第四条也是最实在的一条先把一台机器完整跑顺再考虑批量。VPS 架设这事看着是开很多台实际上难点全在第一台——网络通不通、初始化对不对、性能达不达标这些问题在第一台上暴露出来成本最低。等二十台一起开出来再发现问题返工的工作量是指数级增长的。我现在的习惯是每加一种新配置都先开一台灰度跑一周确认没问题再推广慢一点但省心。
