简介这是一份《云计算基础与应用》第二章“云计算技术架构”的个人学习笔记PDF面向正在学习云计算课程、准备期末或相关认证的高校学生与自学者。内容按课堂章节整理从服务商视角系统梳理云计算三层架构即基础架构层IaaS、中间层PaaS和应用层SaaS并延伸到云管理层的账号管理、配置管理、安全管理、流量管理、计费管理和SLA监控等模块同时较详细地介绍了计算虚拟化、存储虚拟化、网络虚拟化以及全虚拟化与半虚拟化的区别并以KVM/QEMU为例说明主流实现方式。资源包含1个独立PDF文件整体约8.85MB结构紧凑方便手机阅读或打印文末还配有对应的随堂选择题便于对照教材复习和查漏补缺。该笔记已有358人学习浏览特别适合在学完教材后用它快速回顾云计算技术架构的核心脉络。1. 这一章解决什么问题把“云”从概念拆成能画出来的架构我拿到《云计算基础与应用第二章云计算技术架构.pdf》时第一反应是这大概率不是一本纯理论的教材章节而是要让读者在脑子里建立一张“云到底是怎么搭起来的”全景图。很多人在这一步卡住不是因为看不懂名词而是因为看了 IaaS、PaaS、虚拟化、容器、软件定义存储这些词却不知道它们之间的依赖关系更不知道哪一个组件挂了对业务有什么影响。这一章的价值就是把“云计算”从营销词还原成一套可拆解的技术架构控制平面和数据平面怎么分工计算网络存储三条线怎么组织开源和商业方案各自的取舍在哪里。适合读这一章的人不只是学生。想做云计算运维、准备架构师面试、或者公司里要从传统机房往云架构迁移的工程师都需要先把这套骨架立住。下文我会按这一章最常见的课程框架往下拆同时补上我在实际环境里复现这套架构时的参数、命令和血泪经验。2. 四层架构模型从物理机到云主机的每一层在解决什么问题2.1 基础设施层先把计算、存储、网络三块物理资源“池化”传统机房里的服务器一台机器装一个操作系统跑一个业务利用率低、故障时业务跟着宕机。云计算架构的第一步就是把散落的物理服务器变成可以被统一调度的资源池。这层在架构图里通常叫基础设施层包含三个核心部分计算资源池、存储资源池、网络资源池。计算资源池的载体是服务器关键是 CPU 的虚拟化能力。Intel 的 VT-x、AMD 的 SVM以及内存相关的 EPT 特性决定了这台机器能支撑多少虚机密度。实际规划时我一般按物理核数的 80% 参与超分计算CPU 超分比控制在 1:4 以内内存则按 1:1.5 谨慎超分因为内存超分的回收机制不如 CPU 成熟内存资源耗尽会导致宿主机 OOM直接拖垮同机的所有虚机。存储池这块传统架构是每个服务器自带硬盘云架构要求把存储从计算节点里解耦出来。我一个项目里用 Ceph 做分布式的块存储三副本策略下可用容量是裸容量的三分之一。很多团队第一次规划时没算清这个损耗等扩容才发现预算翻了三倍。网络池则是把物理交换机的能力抽象成虚拟网络后面细讲。2.2 虚拟化层Hypervisor 为什么是架构里的“腰部”资源池是死的要变成可分配的云主机必须靠虚拟化层。这一层的主角是 Hypervisor它直接运行在物理机上负责把 CPU 指令转发、内存地址转换、磁盘 IO 重定向这些底层操作封装成一个个独立的安全边界。主流的两种路线差异很大。Type 1 型 Hypervisor 直接跑在硬件上典型代表是 VMware ESXi 和 KVM性能和隔离性更好生产环境几乎都是这条路线。Type 2 型比如 VirtualBoxHost 操作系统上再装虚拟化软件延迟高只适合开发和教学。在云计算技术架构里KVM 是最常见的底座因为它和 Linux 内核深度绑定能直接利用内核的调度器和内存管理机制。这里有个关键概念叫 QEMU它负责模拟设备KVM 负责处理 CPU 和内存的虚拟化。在 OpenStack 架构里Nova-compute 组件就是通过 libvirt 调用 KVM 的 API 完成虚机生命周期管理的。做个类比KVM 是发动机QEMU 是变速箱libvirt 是仪表盘nova-compute 是驾驶员。2.3 平台层与软件定义一切为什么 OpenStack 被叫作“云的操作系统”有了 KVM可以在一台机器上开多个虚机但运维人员还是得手动登录宿主机敲命令算力没法自助申请。平台层的出现就是为了把这套手工操作变成自助服务。平台层向下管理虚拟化资源向上提供 API用户通过网页或命令行就能申请一台云主机全程不需要管理员介入。这个层的核心是软件定义三个关键词软件定义计算、软件定义存储、软件定义网络。计算由 Nova 管存储由 Cinder 管网络由 Neutron 管。整个平台围绕统一 API 来设计所以 OpenStack 本质是“云的 OS”它自己不生产计算能力只是把底层零散的能力编排成标准服务。这层选型时最容易纠结的问题是用 OpenStack 还是直接用 Kubernetes。我的判断标准是如果你要对外提供“云主机”需要完整的租户隔离和存储卷管理选 OpenStack如果业务已经是容器化只需要调度工作负载直接上 Kubernetes。前者偏重“资源售卖”后者偏重“应用编排”两者不是替代关系很多生产环境是各跑各的。2.4 服务层与架构分层表从 IaaS 到 SaaS 的职责边界教学章节里IaaS、PaaS、SaaS 是一定会讲的但很多读者背完定义后仍然分不清边界到底在哪。我自己的理解方式是把它们当成“厨房三段论”IaaS 提供炉灶和锅虚拟机、存储、网络PaaS 提供半成品菜包数据库中间件、运行时环境SaaS 提供成品菜直接打开就能用的 Web 应用。它们的运维责任边界是面试里常考的点。IaaS 模式云服务商只负责物理机房到虚拟化层虚机内的 OS、应用、数据全由用户自己管PaaS 模式服务商把 OS 也包了用户只写业务代码SaaS 模式用户连代码都不用管只管业务配置。以主流的公有云平台为例各服务模式的计费方式和故障责任完全不同。从技术架构角度看云平台最重要的能力是“多租户隔离”SaaS 层看到的是应用级隔离PaaS 层看到的是容器或进程级隔离IaaS 层则是虚机级的硬隔离。三层架构的隔离粒度逐层递减但资源利用率和交付效率逐层递增这是架构选型时必须接受的一对矛盾。架构层核心组件典型技术运维边界交付物基础设施层物理机、存储、交换机RAID、ToR 交换机、UPS服务商资源池虚拟化层HypervisorKVM、QEMU、libvirt服务商虚机、虚拟网络平台层编排调度OpenStack、K8s服务商API、自助服务服务层应用交付DBaaS、Web 应用用户多数场景业务能力3. 把架构跑起来用开源组件复现一套最小云计算技术架构3.1 先定组网方案控制节点、计算节点、存储节点应该怎么分工理论要落地第一步不是敲命令而是先把物理拓扑画出来。按课程第二章的经典“三节点最小架构”最常用的部署方式是三个节点分别承担不同角色控制节点跑 MySQL、RabbitMQ、Keystone 认证、Nova API、Neutron Server计算节点跑 nova-compute 和 neutron-openvswitch-agent存储节点跑 Ceph 的 MON 和 OSD 进程。生产环境至少要两台控制节点做高可用但复现这套架构时单控制节点足够。我的建议是物理机内存至少 32GB因为光控制节点的组件加起来就占 12GB 以上计算节点上跑一台测试虚机又要预留 4GB。网络方面三个节点之间至少需要两块网卡一块管理网跑 API 和内部通信一块数据网跑虚机的业务流量。如果没有条件配物理网卡用 Linux Bridge 加 VLAN 子接口也能模拟性能差但逻辑是对的。3.2 用 PackStack 在单机快速拉起一套 OpenStack命令与参数先明确一点生产环境一般用 Kolla-Ansible 做容器化部署但学习和复现这套架构时我推荐 PackStack它是基于 RDO 项目的一键部署工具支撑单节点或三节点的快速验证。部署前环境要求CentOS Stream 9 或 RHEL 9 兼容系统关闭 NetworkManager 对数据网卡的管理配置好软件源。执行过程极简关键命令如下# 安装 PackStack 工具包 yum install -y centos-release-openstack-caracal yum update -y yum install -y packstack # 先生成配置文件再按环境修改 packstack --gen-answer-fileanswer.ini # 修改关键参数主要关注下面三个 # CONFIG_NEUTRON_OVS_BRIDGE_IFACESeth1 # eth1 换成你的数据网卡名 # CONFIG_KEYSTONE_ADMIN_PWAdmin2024 # 管理员密码 # CONFIG_CINDER_VOLUMES_SIZE50G # 块存储卷组的容量配置文件按需修改后执行安装packstack --answer-fileanswer.ini安装完成后系统会输出一个访问地址和登录账号用浏览器打开 Dashboard 就能看到图形化界面。PackStack 背后的逻辑是它在控制节点上自动启动了 MariaDB、RabbitMQ、Keystone、Nova、Neutron、Horizon 这一整套服务并通过 Puppet 完成配置分发。整个安装过程 30 分钟上下最后验证的方式是执行source keystonerc_admin这个环境变量文件然后跑openstack service list能看到所有服务都处于 enabled 状态就算成功。我在两个项目里都用这套单节点方式做过演练踩过的坑集中在网卡配置和 DNS 上数据网卡必须配成静态 IP且不要在网卡配置里写 GATEWAY否则 Neutron 的 L3 Agent 会报路由冲突。3.3 创建第一台云主机和第一个租户网络验证架构是否成立组件起来了不等于架构通了。必须完整走一遍“创建网络 → 创建虚机 → 分配浮动 IP → SSH 登录”的流程才能确认控制平面和数据平面都正常工作。命令行操作如下# 加载管理员环境变量 source keystonerc_admin # 创建租户网络 192.168.100.0/24 openstack network create demo-net openstack subnet create demo-subnet \ --network demo-net \ --subnet-range 192.168.100.0/24 \ --gateway 192.168.100.1 \ --dns-nameserver 114.114.114.114 # 创建路由并接入外部网络实现虚机访问外网 openstack router create demo-router openstack router add subnet demo-router demo-subnet openstack router set demo-router --external-gateway public # 创建云主机类型、导入镜像并启动虚机 openstack flavor create m1.small --vcpus 1 --ram 1024 --disk 10 openstack image create cirros --disk-format qcow2 \ --container-format bare --file cirros-0.6.2-x86_64-disk.img openstack server create test-vm \ --flavor m1.small --image cirros \ --network demo-net解释下这些命令的逻辑网络是云主机的“血管”必须先建好 network 和 subnet 才有地方挂接。router 的作用是把租户网络的流量转发到外部网络相当于给虚机装了“出口网关”。flavor 是虚机的规格模板镜像则是虚机的操作系统来源。整套流程最大的价值不是跑通命令而是理解 Neutron 的网络模型租户网络是隔离的虚拟二层外部网络是物理二层虚拟路由器负责两者之间的转发。参数层面生产环境里 subnet 的--dns-nameserver建议用云平台内部的 DNS 或公司统一 DNS不要照抄公共 DNS因为内网域名的解析需求跟公网不一样。镜像方面CirrOS 只有几十兆启动极快非常适合作连通性测试真业务再换 CentOS 或 Ubuntu 云镜像。4. 复现与落地中最容易翻车的五个环节4.1 数据网卡配置被 NetworkManager 接管导致网络节点起不来现象neutron-openvswitch-agent 反复重启虚机创建成功但内网不通openstack network agent list里显示:-)状态异常。原因PackStack 安装时要求把数据网卡交给 Open vSwitch 管理但系统里的 NetworkManager 抢先接管了网卡导致 OVS 无法把物理网卡桥接进 br-ex 网桥。这是安装时最频繁的坑。解决安装前把数据网卡从 NetworkManager 中移除# 针对 eth1 网卡写 NetworkManager 的配置文件禁用接管 nmcli dev status nmcli dev set eth1 managedno systemctl restart NetworkManager之后重新执行openstack network agent list确认状态。以后不管用哪套部署工具第一步都是先把网络角色理清管理网归 NetworkManager 管数据网必须交给 OVS这个原则不能乱。4.2 Keystone 认证超时时间不同步被忽略的后果现象执行openstack token issue报 HTTP 401或者认证服务连接超时日志里出现Keystone endpoint not found类错误。原因OpenStack 走的是 PKI token 认证体系对时间偏差极其敏感。节点间时间差超过 5 分钟token 直接判无效。很多人排查了半天密码和网络结果就是 NTP 没配。解决所有节点强制安装并启动 chronyyum install -y chrony systemctl enable chronyd --now chronyc sources -v # 确认已同步三节点架构里控制节点配外网时间源计算节点和存储节点指向控制节点的 IP。这条经验在任何分布式架构里都通用Kubernetes、Ceph 集群时间不同步也会出现各种诡异问题。4.3 虚机磁盘 IO 卡成狗存储节点没有用 SSD 做 OSD现象云主机能起来但一跑dd if/dev/zero of/tmp/test bs1M count1024速度只有 50MB/s 左右数据库类业务直接超时。原因计算节点把虚机磁盘文件放在本地 SATA 盘上多台虚机并发写时磁盘寻道成为瓶颈。很多复现环境不重视存储层认为能装 OpenStack 就行结果性能测试全翻车。解决如果预算有限至少给存储节点配一块 SSD 专门放 OSD 的 WAL 和 DB 分区数据分区可以用 HDD。用 Ceph 时BlueStore 后端允许把db_wal单独指定到 SSDIOPS 能提升几倍。生产环境的标准做法是OSD 数量按故障域设计每节点至少 3 块盘副本策略变为 2 副本加 1 仲裁容错和成本的平衡点。4.4 Nova 调度失败可用域和资源超分没配明白现象openstack server create到ACTIVE后立即变ERROR查看 nova-compute 日志发现No valid host found。原因最常见的两种情况一是没给计算节点设置可用域调度器找不到目标二是镜像和 flavor 的架构不匹配比如虚拟化平台是 x86_64 却导入了 ARM 镜像。解决给计算节点显式配置可用域openstack aggregate create prod-compute openstack aggregate add host prod-compute compute01 openstack aggregate set --property availability_zoneprod-az prod-compute创建虚机时指定--availability-zone prod-az。如果是嵌套虚拟化环境还要检查宿主机/proc/cpuinfo是否暴露了 VMX 标志没有的话 KVM 会退化成 QEMU 纯软件模拟模式创建虚机的速度慢到怀疑人生。4.5 浮动 IP 不通安全组规则默认全放行成了最大的错觉现象虚机有浮动 IP从外部 ping 不通但控制节点上ping 虚机内网IP是通的。原因很多人误以为租户网络建好后所有流量默认放行。实际上 Neutron 的安全组默认拒绝所有入站流量唯一放行的是 SSHPackStack 安装时默认生成的规则只开了 22 端口。ICMP 和业务端口都要显式添加。解决openstack security group rule create default \ --protocol icmp --ingress openstack security group rule create default \ --protocol tcp --dst-port 80:80 --ingress这也是生产环境里的常见事故源开发反馈服务连不上最后发现是安全组少了端口。把安全组当成云上的防火墙来管理规则变更要走工单流程不能随手改。5. 从经典架构到云原生技术架构演进与运维工程师的重点转移5.1 经典三层架构的负载均衡与高可用设计OpenStack 时代的典型高可用方案是控制节点用 Pacemaker 做 VIP 漂移数据库用 MariaDB Galera 多主同步消息队列用 RabbitMQ 镜像队列负载均衡用 HAProxy 对外提供一个统一入口。这套方案的优缺点都很明显组件多故障链路长但稳定后非常抗造。落地上我会给控制节点规划三个 VIP一个给 Dashboard 和 API 入口一个给数据库一个给消息队列。每台控制节点同时跑全部服务Pacemaker 通过健康检查决定 VIP 在哪个节点存活。这套架构最让人头疼的是脑裂问题两个节点同时抢 VIP解决办法是启用仲裁设备让第三节点在冲突时投票判决。5.2 容器化与 Kubernetes 打破传统架构边界IOE 架构IBM 小型机、Oracle 数据库、EMC 存储到云原生架构的演进本质上是从“物理机绑定”走向“应用无关化”的过程。经典云架构里虚机是交付单元云原生架构里容器是交付单元Kubernetes 替代了 Nova 和 Neutron 的部分职责。从技术架构角度对比OpenStack 的 Neutron 提供的是二层和三层的网络抽象而 Kubernetes 的 CNI容器网络接口插件比如 Calico采用纯三层的 BGP 路由模式取消了 VXLAN 封装转发性能更好。存储侧OpenStack 用 Cinder 提供块存储卷Kubernetes 通过 CSI容器存储接口接入 Ceph 的块设备或文件系统。平台侧OpenShift 这类发行版甚至把镜像构建、灰度发布、服务网格全部纳入平台能力。5.3 云计算运维工程师在新架构下守住的技术底线工具链变了但底层原理没变。Kubernetes 的调度器在做的事情跟 Nova 的 FilterScheduler 没有本质区别都是根据资源水位过滤掉不满足条件的节点再按打分策略选最优节点。CNI 插件做的事跟 Neutron 的 DHCP Agent 和 L3 Agent 做的事也类似给 Pod 分配 IP、做路由转发。换个角度来理解OpenStack 的控制平面是“面向资源的编排”Kubernetes 的控制平面是“面向应用状态的编排”。云运维工程师如果能把 OpenStack 时代的控制面原理搞透学 Kubernetes 的调度和网络模型会顺很多。我面试时反复跟候选人强调一个观点架构可以演进但“控制平面高可用”“数据平面低延迟”“租户隔离安全边界”这三件事永远是不变的底线。把这些守住无论底层是虚机还是容器架构都不会出大问题。架构演进这块日常运维中最值得盯的指标是“云覆盖度计算”即云平台上承载的业务占全部业务的比例。很多传统企业说“上云”实际覆盖度不到三成关键业务还在物理机跑导致运维团队要同时维护两套环境成本翻倍。逐步提高云覆盖度把批量和弹性需求明显的业务先迁移比一次性推倒重来更稳。6. 把整章知识内化成自己的技能一张架构图加一套验收清单学这一章最忌讳的是“看懂每个名词串不成一条线”。我习惯的做法是合上书从零开始画一张云架构图从物理资源画到租户虚机标注每个组件之间的通信协议和端口。能独立完成这张图才算真正吸收了这一章的架构逻辑。画图时可以对照下面这份验收清单逐项问自己验收问题答不出来的话去看哪里虚机的创建流程从用户点击到后端调度经历了哪几个组件Nova API、Keystone、RabbitMQ、nova-compute 的交互顺序Neutron 里 br-int、br-tun、br-ex 各解决什么问题流表转发路径、VXLAN 隧道、外部网络桥接Ceph 的 RBD 和 Cinder 的 NFS 后端有什么区别RBD 是块设备级分布式存储NFS 是文件级网络存储控制节点高可用的最小组件集是什么Pacemaker、HAProxy、MariaDB Galera、RabbitMQ 镜像队列容器网络 CNI 与 Neutron 网络模型的核心差异在哪二层隧道 vs 三层路由、Pod IP vs 虚机 IP把自己当成面试官挑一个问题往深挖比如“虚机从创建到可以 SSH 登录中间经过了哪些 DHCP 和 Metadata 请求”。这个细节能讲清楚说明对架构层的数据流有了真实理解而不只是会背服务名。最后一个我自己的习惯在架构图旁边标注“如果某某组件挂了用户会看到什么故障”。比如 RabbitMQ 挂了新建虚机会卡在调度阶段已有的虚机网络通常不受影响Ceph MON 全挂虚机磁盘 IO 直接不可用业务表现为焦油坑式的卡顿。提前把这些故障场景想清楚真出问题时你就能走最短路径定位而不是从底层一层层往上查。第二章的技术架构是整个“云计算基础与应用”这门课的承重墙前面的概念在这里汇合后面的运维、调优、安全全都建立在它之上。理解它最好的方式不是背结构图而是在自己搭的测试环境里反复拆装翻几次车之后很多细节就自然记住了。希望帮到你。本文还有配套的精品资源点击获取