设计 IaaS 平台：虚拟化、调度与计费
设计 IaaS 平台：虚拟化、调度与计费
基础设施即服务（IaaS）是云计算的基石，它把计算、存储和网络等物理资源抽象为可按需使用的虚拟资源。本教程将从零开始，带你理解一个可运营的 IaaS 平台的三个核心模块：虚拟化层如何生成资源、调度系统如何分配资源、以及计费引擎如何衡量价值。我们会以最主流的技术选型为脉络，给出具体的设计思路与数据流向，使你既能把握全局，也能深入细节。
1. 虚拟化：如何把物理机变成可售卖的资源单元
虚拟化（Virtualization）是 IaaS 的资源产生器。没有它，就没有弹性、隔离、可迁移的虚拟机或容器。这一层核心要解决三个问题：CPU/内存的分割、存储的抽象和网络的虚拟化。
1.1 计算虚拟化：KVM 与硬件辅助
在开源 IaaS 设计中，KVM（Kernel-based Virtual Machine）几乎是不二之选。它利用 Intel VT-x 或 AMD-V 硬件虚拟化扩展，让每个虚拟机（VM）跑在独立的虚拟 CPU（vCPU）与地址空间上。
- vCPU 的本质：不是物理线程的绑定，而是宿主机调度实体。物理 CPU 通过时间片轮转，让每个 vCPU 获得算力。设计上，vCPU 总数可以超分（overcommit），但需要根据负载类型决定超分比例——计算密集型建议 1:1，轻量 Web 或开发环境可达 1:4。
- 内存管理：KVM 通过 EPT（扩展页表）将客户机物理地址映射到宿主机物理地址。关键设计点是 内存气球（balloon） 与 内存超分。virtio-balloon 驱动允许宿主回收未使用的客户机内存，但在超分时需配合内核同页合并（KSM）提升密度。超分比率需基于工作负载的内存重码率谨慎设置，通常不高于 1:1.5，否则可能引发严重的交换风暴。
- 落地选择：libvirt 是管理 KVM 的通用 API 层，而 LXD/LXC 可作为轻量级容器方案补充。一个完整的 IaaS 虚拟化层通常会同时托管 VM 与容器，通过统一的计算调度框架纳管。
1.2 存储虚拟化：从本地磁盘到分布式存储
虚拟机需要一个根磁盘和数据盘，设计要求是“高可用、可迁移、快照与克隆”。
- 本地存储与共享存储的权衡：本地 SSD 性能极高，但无法支持热迁移（live migration）；共享存储如 NFS 或 Ceph RBD 可满足迁移需求，但网络时延与带宽是瓶颈。现代 IaaS 多采用 分布式存储池，如 Ceph，通过多副本或纠删码实现高可用，并暴露 RADOS 块设备给 qemu-kvm。
- 镜像与快照流：基础镜像通过 copy-on-write (qcow2) 分发。虚拟机往往有一个后台级联的快照链：
base-image <-- snapshot1 <-- snapshot2 ...。后台需定期合并快照（block commit），否则磁盘 IO 路径过长，性能会退化。 - 本地 SSD 的加速角色：利用 NVMe 本地盘做缓存层，比如 Ceph 的 BlueStore 直接管理裸盘，或使用 dm-cache/bcache 将热点数据缓存在本地，再往远程存储写入。
1.3 网络虚拟化：从二层隔离到 SDN
在多租户环境中，虚拟网络需要保障租户之间严格隔离，同时允许自定义拓扑、安全组与浮动 IP。
- 隔离方案：VLAN 标签只有 12 bit（最多 4096 个），在大规模云平台中远远不够。因此更常用的是覆盖网络（Overlay）：VXLAN、Geneve 等，将二层帧封装在 UDP 包中传输，利用 24 位 VNI 支持千万级隔离域。
- 虚拟交换机与路由：Open vSwitch (OVS) 是事实标准。需设计一个控制平面（如 SDN 控制器或 Neutron server）来下发流表，实现分布式虚拟路由器（DVR）和东西向流量的本地转发。
- 安全组和 QoS：安全组规则应转化为 OVS conntrack 流表，或下沉到 iptables/nftables。带宽限速常用 Linux tc (htb/fq) 或 OVS 的 ingress policing。
2. 调度：如何在海量物理机中为资源找到最佳归宿
一旦有了可分配的资源池（计算节点、存储池、网络段），就需要一个调度器来决定每台虚拟机或容器应该“降落”在哪台物理机上。此处设计直接影响资源利用率、故障域隔离和客户体验。
2.1 调度输入：资源请求与约束
一个标准的调度请求至少包括：
- 资源请求：vCPU 数量、内存大小（MB）、根磁盘容量、额外的块设备及大小、网络带宽需求。
- 亲和/反亲和规则：同一租户的 VM 尽量分散在不同机架（反亲和），或某些数据库实例必须放在同一台宿主机（亲和）。
- 故障域要求：指定可用区（AZ）、主机集合（host aggregate）或 NUMA 拓扑感知。
- 特殊硬件需求：GPU、FPGA、巨页、SR-IOV VF 等。
将这些请求与物理机实时的**资源存量（inventory）**进行匹配，是调度的核心。
2.2 过滤器与权重：经典的调度框架
大多数 IaaS 调度器（如 OpenStack Nova FilterScheduler）采用过滤链 + 权重链的模式，易于扩展和自定义。
过滤（Filtering）阶段：按照硬约束过滤掉不满足要求的主机。常见过滤器：
RamFilter/CoreFilter：资源是否足够。DifferentHostFilter：反亲和，不能和指定主机在同一节点。SameHostFilter：亲和，必须在指定主机上。AggregateInstanceExtraSpecsFilter：匹配元数据标签，如ssd=true。ImagePropertiesFilter：镜像要求的主机特性，比如架构x86_64或arm64。
过滤后留下的候选主机构成一个集合。
权重（Weighting）阶段：对候选主机打分，按分数高低排序，选择最优。默认权重函数可能是：
得分 = w1 * (空闲内存) + w2 * (CPU剩余) + ...
也可以自定义：倾向低负载（空闲资源多）、最小化碎片、首选 SSD 节点等。建议引入反熵机制，避免新请求总是落在刚刚刷新的节点上（可加入随机因子）。
2.3 高级调度特性
- 重调度与疏散：由于物理机故障或计划维护，需要将虚拟机迁移。需实现疏散调度，优先选择其他可用区或健康节点，此时需重新执行调度逻辑并与热迁移配合。
- 抢占与超发回收：在吞吐量优先的场景，可允许低优先级任务被高优先级抢占。例如容器平台中，Burstable Pod 可能被驱逐，Kubernetes 的抢占逻辑值得借鉴。
- 资源碎片整理的策略：长期运行后，物理机资源碎片化严重。可设计重整调度器（rebalancer），通过监控碎片指数，触发不敏业务的冷迁移。
3. 计费：如何将资源消耗准确、公平地转化为可收费的金额
计费（Billing）是 IaaS 商业化的最后一环，它连接资源使用与财务入账。一个可靠的计费设计要处理好计量、费率和帐单三大要素。
3.1 计量：精准采集使用量
计费的元数据来自对虚拟资源使用量的持续采集。通常有两种获取方式：
- 轮询采集（Polling）：计费代理周期调用虚拟化层 API，获取每实例的运行时长、vCPU 占用峰值、内存平均值、网络进出字节数、磁盘 IOPS 与吞吐量。轮询间隔通常 5-15 分钟。为了避免数据丢失，须在每次采集后持久化原始样本。
- 事件驱动采集：监听云平台的消息队列（如 RabbitMQ）中的实例生命周期事件：
create、resize、suspend、delete等。事件能提供精确的状态变更时间点，弥补轮询的采样盲区。推荐做法是 事件为主、轮询为校验。
计量数据需经过聚合与清洗，形成衡量指标，例如：按小时计量的“vCPU小时”、按流量计的“外网流出量 GB”。存储类资源通常按 GB月容量计费，快照按总空间计费，负载均衡器按实例数+带宽组合计费。
3.2 费率模型：从简单到精细
基础模型是按用后付费（postpaid）：每个计费周期（月/日），根据计量数据乘以商品单价，生成账单。单价表是一个多维度映射：
- 按实例规格族（通用型、计算型、内存型）
- 按区域（华北、华东、海外）
- 按可用区类型（标准、高性能）
- 按操作系统（Linux 免费，Windows 增值）
- 按网络带宽模式（按带宽固定、按流量）
进阶模型包括：
- 包年包月（预付费）：一次性支付固定时长，单价打折。需处理续费、升降配、自动续费逻辑。
- 资源包/容量包：允许提前购买 CPU 小时数、流量包，使用时自动扣减。
- 竞价实例：动态定价，基于当前空闲资源建立供需曲线，出价低于现价时实例回收。
费率模型需支持一个关键的机制：补差与退款公式。当用户从预付费升级为更高配置，应计算剩余价值的抵扣，按比例折算新配置的费用。
3.3 账单生成与扣费流程
一个稳定的计费流水线如下：
- 计量收集 -> 原始数据入消息队列。
- 聚合处理器 -> 从消息队列读取，按租户+资源+计量维度聚合，写入时序数据库或列式存储。
- 定损和账期计算：每日凌晨定时任务，按当前费率计算当日消费，写入账单快照表。上月/上周的账单在账期结束时冻结，生成最终账单。
- 扣费与信用控制：与支付系统对接。对后付费模式，必须设立信用额度与欠费停服机制：欠费超过一定阈值推送预警，超过宽限期则挂起资源（但不删除，保留数据一段时间）。
- 账单展示 API：向用户提供小时级、日级、月度明细以及聚合视图。
为保证一致性和审计，账单数据必须幂等处理，并记录每一次价格变更的时间戳。所有计费逻辑最好做到可重放，即给定同一时间段的历史单价与原始计量，可以重新计算出一致的费用。
4. 总结：将三块拼图连接起来
一个可用的 IaaS 平台，不是这三个模块的简单堆砌，而是通过统一的资源生命周期串联：
- 虚拟化提供资源的创建、变更、删除能力，并暴露准确的容量度量。
- 调度使资源被合理放置在健康、利用率最优的物理节点上，并在故障时重新平衡。
- 计费全程跟踪这些操作和占用的时间，将其货币化，反哺平台的运营。
初学者在开始设计时，可以先从最基础的三问入手：“我的云主机是怎么生成的？”、“为什么它会被创建在这台物理机上？”、“每跑一个小时我要收多少钱？”。带着这三个问题依次深入对应模块，你就能逐渐构建出一个可演进、可商用的 IaaS 系统。