8-7 私有云的构建 · 波仔的云计算课

📄 一句话概括

私有云不是【自己买了一堆服务器】，而是把这堆服务器变成一个【能按需开出来的资源池】——教科书式的画法是四层逻辑架构：硬件资源层（砖和钢筋）、虚拟化层（把硬件变成池）、核心服务层（认证、镜像、计算、网络、存储）、界面层（人看到的那个门户）。自下而上，一层把下面那层的原料加工成上面那层能用的东西——这个【加工链】就是私有云和一堆虚拟机的根本区别。

📝 本节和前面几节的关系

它是 4-17 的【架构图视角】：那一节讲 OpenStack 有哪些组件，这一节把它们摆回它们各自所在的层。

它同时接上 4-16 的【超融合】：那一节是一种【把四层压缩到一层】的做法，这一节讲的是【标准形态下这四层怎么分】—— 理解了分层，才能理解超融合到底把什么压到了一起。

一、私有云和【一堆虚拟机】的区别

很多人第一次听【私有云】，会把它理解成【自己买服务器、自己装虚拟化软件】。 但如果只是这样，那它只是一堆虚拟机，还不是云。

区别在哪？ 看一个场景：

一堆虚拟机：要一台机器，去找管理员，管理员手动开一台给你，等半天。
私有云：要一台机器，登录自助门户，点几下，几分钟后自己就有了。

差别不在【有没有虚拟化】，而在【有没有把这件事变成自动的、自助的】。 而这件自动化的事，需要一整套服务在背后支撑——认证你得有吧（证明你是你）、镜像你得有吧（去哪找操作系统模板）、调度你得有吧（这台开在哪台物理机上）、网络你得有吧（它怎么和别的机器通）。 这些东西叠起来，就是私有云。

二、动手 Demo：私有云的四层架构

看到什么算成功：

==================================================================================================
【Demo 7】私有云的构建：逻辑架构图
==================================================================================================

  【一】四层逻辑架构：谁在上面、谁在下面

  层次          放什么                                      一句话
  ------------------------------------------------------------------------------------------
  界面层        自助门户、计费、工单                        人看到的那一层
  核心服务层    认证、镜像、计算、网络、存储服务            云的大脑
  虚拟化层      Hypervisor 与宿主机系统                     把物理资源切成池
  硬件资源层    服务器、交换机、存储                        真正的砖和钢筋

  自下而上：硬件被虚拟化层汇聚成资源池，
  核心服务层再把资源池变成【能按需开出来的东西】，
  界面层把它交到人手里。这就是【私有云】和【一堆虚拟机】的区别。

  【二】节点角色：一台机器可以兼多职

  角色        跑什么                                  资源特点
  ------------------------------------------------------------------------------------------
  控制节点    认证、API、数据库、消息队列             吃磁盘 IO 和稳定性
  计算节点    承载云主机                              吃 CPU 核数和内存
  存储节点    提供共享存储（如 Ceph）                 吃磁盘容量和 IO
  网络节点    路由、DHCP、地址转换                    吃网络吞吐

  小规模可以把四个角色塞进一台；要撑住生产，
  控制节点至少要 3 台（不然控制面一挂，全都动不了）。

读结果：

第一张表的关键在读法：自下而上读一遍。硬件是死的（服务器就是服务器）；虚拟化层把它【汇聚】成资源池；核心服务层把资源池加工成【服务】；界面层把服务交给用户。 每往上一层，抽象程度高一层、人可以操作的程度也高一层。到了最上面那一层，用户甚至不需要知道下面是物理机还是虚拟机。
第二张表讲的是【逻辑角色】和【物理机器】不是一一对应的。你可以把四个角色塞进一台机器（适合小规模、测试），也可以让一个角色横跨好几台（适合高可用）。 这个自由度正是私有云的复杂度来源——配置灵活，但选错了就很难改。
注意最后一句话：控制节点至少要 3 台。这不是保守——控制节点上跑的是认证和调度，它一挂，整个云就【动不了】了（已有虚拟机可能还在跑，但你没法开新的、没法改配置）。所以控制面是所有组件里最需要冗余的那部分。

三、四层各是什么

硬件资源层——服务器、交换机、存储。这一层是唯一的实体，上面三层都是它的抽象。规划这一层时要先想清网络的划分（管理网、业务网、存储网往往物理分开），因为这决定后面能不能顺畅地跑起来。

虚拟化层——Hypervisor（把物理资源切成虚拟资源的软件）加上宿主机操作系统。它把上面那堆硬件，变成【可以被灵活分配的池】。这一步是【云】能成立的技术前提——没有它，硬件就是一整块，切不开也挪不动。

核心服务层——这是私有云真正的【大脑】，通常包含这几个服务：

服务	作用	一句话
认证	管用户、项目、权限	门卫，所有操作先过它
镜像	存操作系统和软件模板	模板仓库，开机器时来这里取
计算	管虚拟机的生命周期	调度员，决定开在哪台物理机上
网络	管子网、路由、防火墙	让虚拟机互相通、也通到外面
存储	管云硬盘和对象存储	仓库，给虚拟机提供数据盘

界面层——自助门户、计费、工单。这一层决定了【云好不好用】——因为它是在用户和机器之间唯一的那层皮。技术做得再好，如果申请一台机器要填十个表单、等三天审批，那它就不是云。

四、节点角色可以合并

逻辑上是四个角色，物理上却不必是四台机器。合并的原则是自己权衡：

小规模 / 测试环境：四个角色塞进一台——省钱，但没有冗余。
中等规模：控制节点独立（至少 3 台做高可用），计算和存储合并——这是最常见的中庸配置。
大规模：四个角色各成一组，各自横向扩展——运维复杂度最高，但扩展性最好。

这里有一个反直觉的建议：不要一上来就为了【架构完备】把所有角色都拆开、把所有高可用都做上。 复杂度本身会变成新的故障源——组件越多、依赖链条越长，出问题的地方就越多。 正确做法是【从最小可用开始，随着规模增长再拆】。

五、2026 现状

① 私有云的【建构方式】在收敛。 早年自建私有云要手工装一大堆组件、调好多参数；2026 年主流做法是【用容器化工具一键部署】——把控制层的各个服务打包成容器，用编排工具统一拉起。这大幅降低了入门门槛，也让升级变得容易。

② 【最小可用集合】被明确了下来。 现在的实践经验是：认证、镜像、计算、网络这四个核心服务是必须的；块存储、编排、监控可以后加。 一上来就装全套，往往会被后台服务吃掉大量资源——反而不如先把最小集合跑通。

③ 超融合把【四层】压成了【一体】。超融合方案把计算、存储、网络打包成标准化的整机——买来插上就能用，几天就能有一个能跑的私有云。 代价是灵活性降低、价格更高。这正好说明了一件事：分层是【标准形态】，而超融合是【把分层做成商品】。

30 秒实验

想象一下你要给一个小团队（10 个人）搭一套私有云，做两件事：

按 Demo 第一张表，从下到上数一遍：这四层，你打算各用什么？（硬件用几台机器？虚拟化用什么软件？核心服务装哪些？界面用什么？）
再问自己一句：哪一层你最没底？

做完你通常会发现自己【最没底的往往是核心服务层】——因为硬件能买、虚拟化软件能装，但【认证、镜像、计算、网络这几个服务怎么配起来、怎么不出问题】，才是真正吃经验的地方。 这个感受恰好解释了为什么私有云的难点不在【买设备】，而在【运维】。

常见误区

错误：私有云就是把服务器虚拟化一下。——纠正：虚拟化只是其中一层，而且是【最下面】的那一层。 光有虚拟化，你得到的是一堆虚拟机和一堆手动操作；要变成【云】，还得有认证、镜像、调度、网络这些服务，把它们变成【按需自助】的。所以【虚拟化】是必要条件，不是充分条件——缺了上面几层，它就不是云。
错误：架构当然越完备越好，所有角色都拆开、所有高可用都做上。——纠正：复杂度本身是有代价的。组件越多、依赖越长，能出故障的地方就越多，运维难度也越大。一个由十个组件组成、但没人能完全掌握的私有云，可靠性可能还不如一个由三个组件组成、但团队了如指掌的。所以正确姿势是【按需生长】：从最小可用集合开始，规模涨了再拆、再补高可用。
错误：控制节点和计算节点一样，挂一台就少一点算力。——纠正：它们挂掉的后果完全不同。计算节点挂一台，只影响跑在它上面的那几台虚拟机；控制节点挂了，整个云平台就【动不了】了——你没法开新机器、没法改配置、没法做任何管理操作（已经在跑的虚拟机可能还活着，但你指挥不动它们）。所以控制节点的高可用优先级，远高于计算节点。
错误：私有云一定比公有云便宜，因为它不用付租金。——纠正：私有云省掉的是租金，多出来的是【设备折旧 + 机房 + 电力 + 运维人力】。尤其【人力】这一项，最容易被低估——一个能撑住生产环境私有云的团队，成本远高于大多数人的预估。 所以它划不划算，取决于【规模】和【合规要求】：规模够大、或监管要求必须本地化时，它才划算；规模小的时候，公有云通常更省。

自测三问（点开对答案）

1. 为什么说【私有云】和【一堆虚拟机】的根本区别是【有没有自助服务】？ —— 因为**虚拟化只解决了【资源能切开】，没解决【资源能自助拿到】**。**一堆虚拟机的场景里，开机器这件事仍然要靠人去操作**——**你要申请、要等、要管理员手工配置**。**而云的本质是【按需自助】**：**用户自己登录门户、几分钟拿到资源、不用经过人**。**做到这一点，就需要认证、镜像、调度、网络这一整套服务在背后自动完成。** 所以说到底，**云不是一种硬件形态，而是一种【服务方式】**。 2. 为什么控制节点需要高可用，而且优先级高于计算节点？ —— 因为**它们故障的【影响面】完全不同**。**计算节点挂一台，只损失它上面那几台虚拟机的算力**——**整个云还能正常运转，别的机器不受影响**。**控制节点挂着认证和调度，它一挂，你就【开不了新机器、改不了配置、做不了管理】**——**整个平台从【可用】变成【僵住】**。所以**控制节点是全套组件里最不能单点的那一环**——**至少三台，才有意义。** 3. 为什么建议【从最小可用开始，而不是一上来就全部拆开】？ —— 因为**私有云的运维复杂度会随组件数快速上升**——**每多一个组件，就多一处可能出错、多一个要升级、多一份要监控**。**而一个团队能同时掌握的复杂度是有限的**。**所以正确的路径是：先用最小集合（认证、镜像、计算、网络）跑通、让团队熟悉，等规模真的涨上来了，再逐步拆开、加重冗余。** 这也是 Demo 第二段那句【小规模可以把四个角色塞进一台】背后的道理——**不是偷懒，是【把复杂度控制在能驾驭的范围内】。**

☐ 下一节（8-8 VPC 的构建：VPC 逻辑架构图）