简介这是一份系统梳理云计算核心知识的文档资料适合正在学习云计算导论课程、备考相关认证或希望快速建立整体认知的读者。内容从云计算的产生背景与定义入手逐步展开云计算与IT技术的关系、三类使用模式、对软件产业和商业模式的影响并进一步阐释基础设施特征、效用计算、网格计算、分布式计算、服务器集群与虚拟化等关联概念同时涵盖现存的连续高可用性、一致性、互操作性与标准化等难题以及分层架构和典型企业应用案例。文档按照专题逐条展开便于读者在较短时间内形成较为完整的知识框架也可作为课堂笔记、复习提纲或教学辅助材料使用。资源包仅含1个doc文件大小61KB查阅方便内容结构清晰章节划分明确。目前已有754人学习下载适合需要快速掌握云计算基础概念与脉络的学习者参考。1. 云计算导论开篇先分清上云和买台服务器放机房很多人翻开云计算导论第一反应是上云就是租台远程机器ssh 上去装环境。这个理解错在把云计算当成了网络托管机房。云计算的本质是把计算、存储、网络拆成可独立申请、按量计量、随时回收的基础服务你关心的不再是某台机器配置够不够而是需要多少 CPU 分钟、多少 GB·月存储、多少出网流量。这门课要解决三件事看懂服务模型的边界理解部署模型的取舍以及把第一个应用跑在云上的最小操作路径。对刚接触云平台的后端开发、运维转岗和技术选型的人来说这部分内容比任何版本号都值得先搞清楚。一个反直觉的结论云计算的难点从来不在创建实例的命令而在判断什么该交给云、什么必须留给自己。后文的全部参数与排错步骤都在为这个判断服务。2. 云计算导论核心模型服务模型、部署模型与云基础设施机制2.1 三种服务分界IaaS、PaaS、SaaS 各自管到哪一层云计算导论里最先遇到的抽象模型是管理边界。IaaS 只提供虚拟化后的硬件资源操作系统和中间件归你管PaaS 把运行时和中间件接管你只交付代码和数据SaaS 连应用本身都打包好只剩配置和权限管理。不少初学者把三者当成价格档位实际上它们是责任切分方案选错模型等于选错了运维成本结构。服务模型你负责的层云厂商负责的层典型对象IaaS应用、运行时、OS、中间件虚拟化、物理硬件、网络设备云主机、块存储、VPCPaaS应用代码、业务数据运行时、中间件、OS、硬件托管数据库、容器服务SaaS用户配置、权限策略全部技术栈企业邮箱、协同办公套件判断一个服务属于哪层只看出问题时要谁去登服务器。数据库连接数打满如果是托管数据库服务你只能调整实例规格而不能 ssh 进去改参数这就是 PaaS 的边界。用脚本把职责模型固化成字典适合在导论课件里做对比演示# service_model.py # 三种模型的职责分配用于选型前的管理边界核对 models { IaaS: { tenant: [application, runtime, os, middleware], provider: [hypervisor, hardware, network, storage], }, PaaS: { tenant: [application, data], provider: [middleware, runtime, os, hardware, network], }, SaaS: { tenant: [user_config, access_policy], provider: [application, data, runtime, middleware, os, hardware], }, } for name, m in models.items(): print(f{name}: 租户管 {len(m[tenant])} 层厂商管 {len(m[provider])} 层)这段脚本的逻辑是用两个列表表示管理边界tenant列表越长日常运维负担越重。选型时把待上云的系统按这个结构过一遍能接受厂商锁定就选 PaaS需要定制内核参数只能留在 IaaS办公类系统直接用 SaaS。这是云计算导论里最实用的一条判断链。2.2 部署模型选择公有云、私有云、混合云的取舍点服务模型解决管到哪一层部署模型解决资源放在哪。公有云适合业务波动大、需要快速扩展的互联网应用计费灵活但长期稳定负载的单价未必低于自建私有云适合有明确安全合规要求、资源使用平稳的场景前期建设成本高但单位成本可控混合云把核心业务留在私有环境把突发流量或离线算力放到公有侧这是目前大中型企业最常见的形态。选择时看四个维度成本敏感度、扩容频率、数据驻留要求、团队现有技术栈。团队已经熟悉某套虚拟化平台时硬迁到容器化 PaaS 反而拉长交付周期。云计算导论里的工程模型指的就是这套决策框架先用业务特征匹配部署模型再用部署模型约束服务模型顺序反了就会出现先买了容器服务再回头改造应用结构的返工。2.3 云基础设施机制计算、存储、网络三类构件块如何协同云基础设施机制是云环境的基础构件块针对计算、存储、网络三类资源拆成可编排的最小单元。计算构件以实例规格为单位存储构件分块存储、文件存储、对象存储三种形态网络构件提供 VPC、子网、安全组、负载均衡等隔离与转发能力。三者不是并列关系而是嵌套关系一个云主机必须挂在某个子网里系统盘来自块存储镜像文件却存在对象存储中。存储选择最容易出错导论阶段先把三类存储的挂载形态和延迟特征记住存储类型挂载方式访问延迟适合承载块存储绑定单台实例自建文件系统毫秒级数据库数据盘、系统盘文件存储NFS/SMB 多实例共享毫秒到十几毫秒共享目录、应用日志对象存储HTTPS API无挂载概念几十毫秒级备份、静态站点、数据湖在开源云平台里这三类构件分别由 Nova计算、Cinder块存储、Swift对象存储、Neutron网络提供导论实验环境基本都是这套组合。理解构件块的价值在排错应用超时先查网络构件再看存储延迟最后怀疑计算构件避免在错误层级浪费时间。3. 云计算导论动手实践用 OpenStack CLI 跑通最小云主机3.1 准备认证环境与配额检查无论使用哪家云平台CLI 第一步都是加载认证信息。以 OpenStack 为例认证由 Keystone 完成需要项目名、用户名、密码和认证地址四个要素。真实环境里这些变量通常由平台下发成一个 rc 文件加载前先检查内容# 加载租户认证信息变量名是 OpenStack SDK 约定的标准名称 export OS_PROJECT_NAMEdemo export OS_USERNAMEadmin export OS_PASSWORDYourPassword123 export OS_AUTH_URLhttp://controller:5000/v3 export OS_USER_DOMAIN_NAMEDefault # 查看项目配额确认 vCPU、内存、实例数还有余量 openstack quota show demo --detail逻辑说明OS_AUTH_URL指向 Keystone 的 v3 端点末尾的/v3不能丢OS_USER_DOMAIN_NAME必须显式设置否则认证回落到默认域多人共用环境下容易拿到错误项目的 token。quota show --detail同时显示限制值和已用量重点看cores、ram、instances、volumes四个字段。创建实例报资源不足时八成是配额耗尽而非底层故障先用这条命令排除。配额确认后再看环境里有哪些可用规格与镜像避免用不存在的 ID 创建实例# 列出规格、镜像和网络对应商业云的 instance type、AMI、subnet openstack flavor list openstack image list openstack network list参数说明flavor list的 ID 列在创建实例时要复制引用规格里的 VCPUs 与 RAM 是计费依据image list关注操作系统版本和磁盘格式实验环境优先选qcow2格式的官方镜像network list确认是否存在名为public或external的外部网络没有它后续绑定浮动 IP 会失败。3.2 创建网络、子网、路由与安全组云主机不能脱离网络独立存在标准做法是先建隔离网络再建子网再通过路由器打通外部网络。这个顺序是 Neutron 的依赖关系决定的倒过来只会收到资源不存在的报错# 创建租户隔离网络 openstack network create demo-net # 创建子网网关和 DNS 必须显式指定 openstack subnet create --network demo-net \ --subnet-range 192.168.10.0/24 \ --gateway 192.168.10.1 \ --dns-nameserver 223.5.5.5 \ --dns-nameserver 114.114.114.114 \ demo-subnet # 创建路由器接入外部网络再把子网挂到路由器上 openstack router create demo-router openstack router set --external-gateway public demo-router openstack router add subnet demo-router demo-subnet # 创建安全组只放行 SSH 端口用于实验 openstack security group create demo-sg openstack security group rule create --proto tcp --dst-port 22 \ --remote-ip 0.0.0.0/0 demo-sg参数说明--subnet-range建议避开宿主机网段防止路由冲突--dns-nameserver可传多次内网没有自建 DNS 时至少配一个公共 DNS否则实例通了网络却解析不了域名--remote-ip 0.0.0.0/0表示放行全部来源实验可用生产环境务必换成办公网或跳板机地址段。安全组是云环境里最容易出问题的构件。新建安全组只放行 22 端口时后续用 HTTP 访问业务必然超时。建组时建议一次把需要的协议和端口列全。以下补充 ICMP 放行规则否则后面的 ping 验证步骤会误判为网络故障# 放行 ICMP 供连通性测试--icmp-type -1 表示所有 ICMP 类型 openstack security group rule create --proto icmp \ --icmp-type -1 --remote-ip 0.0.0.0/0 demo-sg提示安全组是白名单式过滤未显式放行的流量一律丢弃。改动规则后立即生效无需重启实例。3.3 创建实例、绑定浮动 IP 并验证 SSH网络就绪后创建实例命令里同时指定规格、镜像、网络和安全组。创建过程是异步的命令返回时实例仍处于 BUILD 状态只有轮询到 ACTIVE 才能继续# 创建云主机demo-key 是提前导入的 SSH 密钥对 openstack server create --flavor m1.small \ --image ubuntu-22.04 \ --network demo-net \ --security-group demo-sg \ --key-name demo-key \ demo-instance # 等待实例进入 ACTIVEERROR 时查看控制台日志定位原因 openstack server wait --wait-until ACTIVE demo-instance参数说明--flavor与--image对应导论里的计算构件与镜像构件镜像架构必须与宿主机一致--security-group指定入方向防火墙策略--key-name指定登录凭据漏掉就只能走控制台密码。实例进入 ERROR 后用openstack console log show demo-instance查看串口日志最常见的失败原因是镜像格式不兼容、所选规格内存低于镜像最低要求。实例启动后内网地址只能在租户网络内访问要从外部登录必须绑定浮动 IP# 从外部网络分配浮动 IP再绑定到实例 FLOAT_IP$(openstack floating ip create public -f value -c floating_ip_address) openstack server add floating ip demo-instance $FLOAT_IP # 确认实例状态与地址信息 openstack server show demo-instance -c status -c addresses # 验证连通性-W 3 指定超时 3 秒 ping -c 4 -W 3 $FLOAT_IP ssh -i demo-key.pem ubuntu$FLOAT_IP逻辑说明-f value -c floating_ip_address让命令直接输出 IP 字段方便在脚本里捕获add floating ip把浮动 IP 与实例固定 IP 做映射。SSH 失败时按顺序排查先看安全组是否放行 22 端口再确认浮动 IP 状态不是 DOWN最后检查私钥权限chmod 600 demo-key.pem是私钥可用的前提。这套流程跑通云计算导论的实验环节就完成了大半。4. 云计算导论工程延伸虚拟化、弹性伸缩与云覆盖度计算4.1 虚拟化是云主机的翻译层云主机能秒级创建是因为它并非真实机器而是运行在宿主机上的虚拟机。虚拟化层把 CPU 指令、内存访问、磁盘 IO 翻译成物理硬件可执行的格式云平台在此基础上叠加镜像与快照能力。导论阶段只需要理解三个层级镜像生成实例、实例运行在宿主机上、宿主机由虚拟化层调度排错时按这个层级逐层上移。实例规格与物理机的换算关系常被忽略。一台 8 核 16GB 的宿主机若所有实例独占 CPU最多只能开两台 4C8G 实例云平台通过超分提高利用率代价是 CPU 竞争带来性能波动。生产环境里数据库类实例应启用 CPU 绑定NUMA pinningWeb 前端只要不做性能基准测试超分是更经济的选择。这是导论课堂不会细讲、但运维一定会遇到的取舍。4.2 弹性伸缩的触发条件与冷却时间弹性伸缩是云环境的核心能力监控指标超过阈值后自动增加实例回落后自动减少。配置时真正要调的参数只有五个初始值参考下表参数推荐初始值说明触发阈值70% CPU太低导致频繁扩缩容太高来不及响应聚合周期300 秒监控采集粒度必须与监控系统对齐评估周期数2连续两轮超阈值才触发抗偶发抖动冷却时间600 秒扩容后等待新实例就绪的窗口最大实例数10必须显式设置防止资源失控在 OpenStack 环境里常见做法是用监控告警驱动扩容动作。下面的命令演示注册一个 CPU 高负载告警商业云平台华为云、阿里云等的弹性伸缩服务通常把同样参数做成了控制台表单# 注册告警CPU 超过 70%连续 2 个聚合周期后触发动作 openstack alarm create \ --type gnocchi_resources_threshold \ --metric cpu_util \ --threshold 70 \ --comparison-operator gt \ --granularity 300 \ --evaluation-periods 2 \ --alarm-action log:// \ --resource-id server_uuid \ cpu-high-alarm参数说明--granularity必须与监控采集周期一致配小了收到大量空数据点配大了响应延迟翻倍--evaluation-periods设为 1 时任何瞬时尖峰都会触发扩容负载正常的系统会出现扩了又缩的振荡--alarm-action log://只把告警写入日志用于验证链路通畅生产环境替换成扩容引擎的 webhook 地址。一个容易踩的坑扩容和缩容的冷却时间是两个独立参数。扩容冷却过短流量高峰时实例反复重建缩容冷却过短还在承接请求的实例被立刻回收。经验值是缩容冷却设为扩容冷却的 1.5 到 2 倍。提示弹性伸缩的最小实例数建议设为 1否则负载下降时会触发缩容到 0下一次高峰需要冷启动等待延迟陡增。4.3 云覆盖度计算从数量指标到加权指标衡量一个组织上云上到什么程度常用指标叫云覆盖度定义为已迁移到云环境的业务系统占全部业务系统的比例。最简单的算法按系统数量计算云覆盖度 已上云系统数 / 系统总数 × 100%。这个数字看起来直观但单独使用会掩盖关键系统的迁移状态——非核心系统全部上云、订单交易留在机房数量覆盖率可能高达 80%核心风险一点没降。更可靠的算法是引入业务权重把系统按重要性分级。用 Python 可以清晰演示两种口径的差异# coverage.py # 对比数量口径与权重口径的云覆盖度用于迁移进度管理 systems [ {name: 订单服务, on_cloud: True, weight: 5}, {name: 用户中心, on_cloud: True, weight: 4}, {name: 报表系统, on_cloud: False, weight: 2}, {name: 内部OA, on_cloud: False, weight: 1}, ] count_covered sum(1 for s in systems if s[on_cloud]) count_coverage count_covered / len(systems) * 100 weight_covered sum(s[weight] for s in systems if s[on_cloud]) weight_total sum(s[weight] for s in systems) weight_coverage weight_covered / weight_total * 100 print(f数量云覆盖度: {count_coverage:.1f}%) print(f权重云覆盖度: {weight_coverage:.1f}%)逻辑说明脚本先按数量计算得到 50%再按权重计算得 9/12 即 75%差额就是关键业务未上云的代价。实际运营中权重值可来自系统年度故障损失、用户量或营收占比建议每季度复核。云覆盖度不是汇报用的数字它的作用是给迁移排期提供依据权重覆盖率低的团队下一步优先迁移权重最高的系统而不是挑最省事的凑数量。5. 云计算导论之外的必修课配额监控与资源回收命令5.1 用 quota 和 usage 提前发现资源枯竭实验环境跑熟后最容易被忽略的是配额余量。很多莫名其妙创建失败源于配额耗尽与其等报错不如把检查变成固定动作。云计算运维的每日巡检至少包含两条命令# 查看配额限制与实际用量--detail 区分 limits 和 used openstack quota show --detail demo # 查看项目下实例的累计使用时长单位是小时 openstack usage list --project demoquota show的 used 字段随资源创建回收实时变化usage list给出的是计费用量。两者结合能判断还有没有余量和已经花了多少两个问题比只看控制台总览数字准确。5.2 回收未绑定资源防止隐性成本云平台的计费单位是资源而非项目这意味着删除实例后未绑定的浮动 IP、闲置卷、孤立安全组依然占着配额。定期执行下面三条命令把结果里的每条记录逐一确认后再释放# 找出 DOWN 状态、未被绑定的浮动 IP openstack floating ip list --status DOWN # 找出 available 状态、未被挂载的云硬盘 openstack volume list --status available # 找出 SHUTOFF 状态但仍在计费的实例 openstack server list --status SHUTOFF--status参数按资源状态筛选比人工逐条检查快得多。释放动作对应floating ip delete、volume delete和server delete删除前务必确认资源唯一引用——浮动 IP 释放后原地址无法找回可用卷里若还有数据先做快照再删。5.3 删除项目前的依赖顺序检查项目要整体清理时按依赖顺序操作顺序错了 Neutron 会报资源被占用。标准顺序解绑并删除浮动 IP删除实例从路由器摘除子网接口并删除路由器最后删除子网、网络和安全组。用一条命令验证端口是否完全清理# 列出项目下所有剩余端口正常清空后输出为空 openstack port list --project demo端口列表为空是网络层清理完成的标志。这个检查同样适用于日常排错实例删不掉时先看 port 列表里是否有 stuck 状态的端口手动删除后再删实例比反复重试删除命令有效得多。本文还有配套的精品资源点击获取 云计算导论实践指南：从服务模型到OpenStack云主机部署
简介这是一份系统梳理云计算核心知识的文档资料适合正在学习云计算导论课程、备考相关认证或希望快速建立整体认知的读者。内容从云计算的产生背景与定义入手逐步展开云计算与IT技术的关系、三类使用模式、对软件产业和商业模式的影响并进一步阐释基础设施特征、效用计算、网格计算、分布式计算、服务器集群与虚拟化等关联概念同时涵盖现存的连续高可用性、一致性、互操作性与标准化等难题以及分层架构和典型企业应用案例。文档按照专题逐条展开便于读者在较短时间内形成较为完整的知识框架也可作为课堂笔记、复习提纲或教学辅助材料使用。资源包仅含1个doc文件大小61KB查阅方便内容结构清晰章节划分明确。目前已有754人学习下载适合需要快速掌握云计算基础概念与脉络的学习者参考。1. 云计算导论开篇先分清上云和买台服务器放机房很多人翻开云计算导论第一反应是上云就是租台远程机器ssh 上去装环境。这个理解错在把云计算当成了网络托管机房。云计算的本质是把计算、存储、网络拆成可独立申请、按量计量、随时回收的基础服务你关心的不再是某台机器配置够不够而是需要多少 CPU 分钟、多少 GB·月存储、多少出网流量。这门课要解决三件事看懂服务模型的边界理解部署模型的取舍以及把第一个应用跑在云上的最小操作路径。对刚接触云平台的后端开发、运维转岗和技术选型的人来说这部分内容比任何版本号都值得先搞清楚。一个反直觉的结论云计算的难点从来不在创建实例的命令而在判断什么该交给云、什么必须留给自己。后文的全部参数与排错步骤都在为这个判断服务。2. 云计算导论核心模型服务模型、部署模型与云基础设施机制2.1 三种服务分界IaaS、PaaS、SaaS 各自管到哪一层云计算导论里最先遇到的抽象模型是管理边界。IaaS 只提供虚拟化后的硬件资源操作系统和中间件归你管PaaS 把运行时和中间件接管你只交付代码和数据SaaS 连应用本身都打包好只剩配置和权限管理。不少初学者把三者当成价格档位实际上它们是责任切分方案选错模型等于选错了运维成本结构。服务模型你负责的层云厂商负责的层典型对象IaaS应用、运行时、OS、中间件虚拟化、物理硬件、网络设备云主机、块存储、VPCPaaS应用代码、业务数据运行时、中间件、OS、硬件托管数据库、容器服务SaaS用户配置、权限策略全部技术栈企业邮箱、协同办公套件判断一个服务属于哪层只看出问题时要谁去登服务器。数据库连接数打满如果是托管数据库服务你只能调整实例规格而不能 ssh 进去改参数这就是 PaaS 的边界。用脚本把职责模型固化成字典适合在导论课件里做对比演示# service_model.py # 三种模型的职责分配用于选型前的管理边界核对 models { IaaS: { tenant: [application, runtime, os, middleware], provider: [hypervisor, hardware, network, storage], }, PaaS: { tenant: [application, data], provider: [middleware, runtime, os, hardware, network], }, SaaS: { tenant: [user_config, access_policy], provider: [application, data, runtime, middleware, os, hardware], }, } for name, m in models.items(): print(f{name}: 租户管 {len(m[tenant])} 层厂商管 {len(m[provider])} 层)这段脚本的逻辑是用两个列表表示管理边界tenant列表越长日常运维负担越重。选型时把待上云的系统按这个结构过一遍能接受厂商锁定就选 PaaS需要定制内核参数只能留在 IaaS办公类系统直接用 SaaS。这是云计算导论里最实用的一条判断链。2.2 部署模型选择公有云、私有云、混合云的取舍点服务模型解决管到哪一层部署模型解决资源放在哪。公有云适合业务波动大、需要快速扩展的互联网应用计费灵活但长期稳定负载的单价未必低于自建私有云适合有明确安全合规要求、资源使用平稳的场景前期建设成本高但单位成本可控混合云把核心业务留在私有环境把突发流量或离线算力放到公有侧这是目前大中型企业最常见的形态。选择时看四个维度成本敏感度、扩容频率、数据驻留要求、团队现有技术栈。团队已经熟悉某套虚拟化平台时硬迁到容器化 PaaS 反而拉长交付周期。云计算导论里的工程模型指的就是这套决策框架先用业务特征匹配部署模型再用部署模型约束服务模型顺序反了就会出现先买了容器服务再回头改造应用结构的返工。2.3 云基础设施机制计算、存储、网络三类构件块如何协同云基础设施机制是云环境的基础构件块针对计算、存储、网络三类资源拆成可编排的最小单元。计算构件以实例规格为单位存储构件分块存储、文件存储、对象存储三种形态网络构件提供 VPC、子网、安全组、负载均衡等隔离与转发能力。三者不是并列关系而是嵌套关系一个云主机必须挂在某个子网里系统盘来自块存储镜像文件却存在对象存储中。存储选择最容易出错导论阶段先把三类存储的挂载形态和延迟特征记住存储类型挂载方式访问延迟适合承载块存储绑定单台实例自建文件系统毫秒级数据库数据盘、系统盘文件存储NFS/SMB 多实例共享毫秒到十几毫秒共享目录、应用日志对象存储HTTPS API无挂载概念几十毫秒级备份、静态站点、数据湖在开源云平台里这三类构件分别由 Nova计算、Cinder块存储、Swift对象存储、Neutron网络提供导论实验环境基本都是这套组合。理解构件块的价值在排错应用超时先查网络构件再看存储延迟最后怀疑计算构件避免在错误层级浪费时间。3. 云计算导论动手实践用 OpenStack CLI 跑通最小云主机3.1 准备认证环境与配额检查无论使用哪家云平台CLI 第一步都是加载认证信息。以 OpenStack 为例认证由 Keystone 完成需要项目名、用户名、密码和认证地址四个要素。真实环境里这些变量通常由平台下发成一个 rc 文件加载前先检查内容# 加载租户认证信息变量名是 OpenStack SDK 约定的标准名称 export OS_PROJECT_NAMEdemo export OS_USERNAMEadmin export OS_PASSWORDYourPassword123 export OS_AUTH_URLhttp://controller:5000/v3 export OS_USER_DOMAIN_NAMEDefault # 查看项目配额确认 vCPU、内存、实例数还有余量 openstack quota show demo --detail逻辑说明OS_AUTH_URL指向 Keystone 的 v3 端点末尾的/v3不能丢OS_USER_DOMAIN_NAME必须显式设置否则认证回落到默认域多人共用环境下容易拿到错误项目的 token。quota show --detail同时显示限制值和已用量重点看cores、ram、instances、volumes四个字段。创建实例报资源不足时八成是配额耗尽而非底层故障先用这条命令排除。配额确认后再看环境里有哪些可用规格与镜像避免用不存在的 ID 创建实例# 列出规格、镜像和网络对应商业云的 instance type、AMI、subnet openstack flavor list openstack image list openstack network list参数说明flavor list的 ID 列在创建实例时要复制引用规格里的 VCPUs 与 RAM 是计费依据image list关注操作系统版本和磁盘格式实验环境优先选qcow2格式的官方镜像network list确认是否存在名为public或external的外部网络没有它后续绑定浮动 IP 会失败。3.2 创建网络、子网、路由与安全组云主机不能脱离网络独立存在标准做法是先建隔离网络再建子网再通过路由器打通外部网络。这个顺序是 Neutron 的依赖关系决定的倒过来只会收到资源不存在的报错# 创建租户隔离网络 openstack network create demo-net # 创建子网网关和 DNS 必须显式指定 openstack subnet create --network demo-net \ --subnet-range 192.168.10.0/24 \ --gateway 192.168.10.1 \ --dns-nameserver 223.5.5.5 \ --dns-nameserver 114.114.114.114 \ demo-subnet # 创建路由器接入外部网络再把子网挂到路由器上 openstack router create demo-router openstack router set --external-gateway public demo-router openstack router add subnet demo-router demo-subnet # 创建安全组只放行 SSH 端口用于实验 openstack security group create demo-sg openstack security group rule create --proto tcp --dst-port 22 \ --remote-ip 0.0.0.0/0 demo-sg参数说明--subnet-range建议避开宿主机网段防止路由冲突--dns-nameserver可传多次内网没有自建 DNS 时至少配一个公共 DNS否则实例通了网络却解析不了域名--remote-ip 0.0.0.0/0表示放行全部来源实验可用生产环境务必换成办公网或跳板机地址段。安全组是云环境里最容易出问题的构件。新建安全组只放行 22 端口时后续用 HTTP 访问业务必然超时。建组时建议一次把需要的协议和端口列全。以下补充 ICMP 放行规则否则后面的 ping 验证步骤会误判为网络故障# 放行 ICMP 供连通性测试--icmp-type -1 表示所有 ICMP 类型 openstack security group rule create --proto icmp \ --icmp-type -1 --remote-ip 0.0.0.0/0 demo-sg提示安全组是白名单式过滤未显式放行的流量一律丢弃。改动规则后立即生效无需重启实例。3.3 创建实例、绑定浮动 IP 并验证 SSH网络就绪后创建实例命令里同时指定规格、镜像、网络和安全组。创建过程是异步的命令返回时实例仍处于 BUILD 状态只有轮询到 ACTIVE 才能继续# 创建云主机demo-key 是提前导入的 SSH 密钥对 openstack server create --flavor m1.small \ --image ubuntu-22.04 \ --network demo-net \ --security-group demo-sg \ --key-name demo-key \ demo-instance # 等待实例进入 ACTIVEERROR 时查看控制台日志定位原因 openstack server wait --wait-until ACTIVE demo-instance参数说明--flavor与--image对应导论里的计算构件与镜像构件镜像架构必须与宿主机一致--security-group指定入方向防火墙策略--key-name指定登录凭据漏掉就只能走控制台密码。实例进入 ERROR 后用openstack console log show demo-instance查看串口日志最常见的失败原因是镜像格式不兼容、所选规格内存低于镜像最低要求。实例启动后内网地址只能在租户网络内访问要从外部登录必须绑定浮动 IP# 从外部网络分配浮动 IP再绑定到实例 FLOAT_IP$(openstack floating ip create public -f value -c floating_ip_address) openstack server add floating ip demo-instance $FLOAT_IP # 确认实例状态与地址信息 openstack server show demo-instance -c status -c addresses # 验证连通性-W 3 指定超时 3 秒 ping -c 4 -W 3 $FLOAT_IP ssh -i demo-key.pem ubuntu$FLOAT_IP逻辑说明-f value -c floating_ip_address让命令直接输出 IP 字段方便在脚本里捕获add floating ip把浮动 IP 与实例固定 IP 做映射。SSH 失败时按顺序排查先看安全组是否放行 22 端口再确认浮动 IP 状态不是 DOWN最后检查私钥权限chmod 600 demo-key.pem是私钥可用的前提。这套流程跑通云计算导论的实验环节就完成了大半。4. 云计算导论工程延伸虚拟化、弹性伸缩与云覆盖度计算4.1 虚拟化是云主机的翻译层云主机能秒级创建是因为它并非真实机器而是运行在宿主机上的虚拟机。虚拟化层把 CPU 指令、内存访问、磁盘 IO 翻译成物理硬件可执行的格式云平台在此基础上叠加镜像与快照能力。导论阶段只需要理解三个层级镜像生成实例、实例运行在宿主机上、宿主机由虚拟化层调度排错时按这个层级逐层上移。实例规格与物理机的换算关系常被忽略。一台 8 核 16GB 的宿主机若所有实例独占 CPU最多只能开两台 4C8G 实例云平台通过超分提高利用率代价是 CPU 竞争带来性能波动。生产环境里数据库类实例应启用 CPU 绑定NUMA pinningWeb 前端只要不做性能基准测试超分是更经济的选择。这是导论课堂不会细讲、但运维一定会遇到的取舍。4.2 弹性伸缩的触发条件与冷却时间弹性伸缩是云环境的核心能力监控指标超过阈值后自动增加实例回落后自动减少。配置时真正要调的参数只有五个初始值参考下表参数推荐初始值说明触发阈值70% CPU太低导致频繁扩缩容太高来不及响应聚合周期300 秒监控采集粒度必须与监控系统对齐评估周期数2连续两轮超阈值才触发抗偶发抖动冷却时间600 秒扩容后等待新实例就绪的窗口最大实例数10必须显式设置防止资源失控在 OpenStack 环境里常见做法是用监控告警驱动扩容动作。下面的命令演示注册一个 CPU 高负载告警商业云平台华为云、阿里云等的弹性伸缩服务通常把同样参数做成了控制台表单# 注册告警CPU 超过 70%连续 2 个聚合周期后触发动作 openstack alarm create \ --type gnocchi_resources_threshold \ --metric cpu_util \ --threshold 70 \ --comparison-operator gt \ --granularity 300 \ --evaluation-periods 2 \ --alarm-action log:// \ --resource-id server_uuid \ cpu-high-alarm参数说明--granularity必须与监控采集周期一致配小了收到大量空数据点配大了响应延迟翻倍--evaluation-periods设为 1 时任何瞬时尖峰都会触发扩容负载正常的系统会出现扩了又缩的振荡--alarm-action log://只把告警写入日志用于验证链路通畅生产环境替换成扩容引擎的 webhook 地址。一个容易踩的坑扩容和缩容的冷却时间是两个独立参数。扩容冷却过短流量高峰时实例反复重建缩容冷却过短还在承接请求的实例被立刻回收。经验值是缩容冷却设为扩容冷却的 1.5 到 2 倍。提示弹性伸缩的最小实例数建议设为 1否则负载下降时会触发缩容到 0下一次高峰需要冷启动等待延迟陡增。4.3 云覆盖度计算从数量指标到加权指标衡量一个组织上云上到什么程度常用指标叫云覆盖度定义为已迁移到云环境的业务系统占全部业务系统的比例。最简单的算法按系统数量计算云覆盖度 已上云系统数 / 系统总数 × 100%。这个数字看起来直观但单独使用会掩盖关键系统的迁移状态——非核心系统全部上云、订单交易留在机房数量覆盖率可能高达 80%核心风险一点没降。更可靠的算法是引入业务权重把系统按重要性分级。用 Python 可以清晰演示两种口径的差异# coverage.py # 对比数量口径与权重口径的云覆盖度用于迁移进度管理 systems [ {name: 订单服务, on_cloud: True, weight: 5}, {name: 用户中心, on_cloud: True, weight: 4}, {name: 报表系统, on_cloud: False, weight: 2}, {name: 内部OA, on_cloud: False, weight: 1}, ] count_covered sum(1 for s in systems if s[on_cloud]) count_coverage count_covered / len(systems) * 100 weight_covered sum(s[weight] for s in systems if s[on_cloud]) weight_total sum(s[weight] for s in systems) weight_coverage weight_covered / weight_total * 100 print(f数量云覆盖度: {count_coverage:.1f}%) print(f权重云覆盖度: {weight_coverage:.1f}%)逻辑说明脚本先按数量计算得到 50%再按权重计算得 9/12 即 75%差额就是关键业务未上云的代价。实际运营中权重值可来自系统年度故障损失、用户量或营收占比建议每季度复核。云覆盖度不是汇报用的数字它的作用是给迁移排期提供依据权重覆盖率低的团队下一步优先迁移权重最高的系统而不是挑最省事的凑数量。5. 云计算导论之外的必修课配额监控与资源回收命令5.1 用 quota 和 usage 提前发现资源枯竭实验环境跑熟后最容易被忽略的是配额余量。很多莫名其妙创建失败源于配额耗尽与其等报错不如把检查变成固定动作。云计算运维的每日巡检至少包含两条命令# 查看配额限制与实际用量--detail 区分 limits 和 used openstack quota show --detail demo # 查看项目下实例的累计使用时长单位是小时 openstack usage list --project demoquota show的 used 字段随资源创建回收实时变化usage list给出的是计费用量。两者结合能判断还有没有余量和已经花了多少两个问题比只看控制台总览数字准确。5.2 回收未绑定资源防止隐性成本云平台的计费单位是资源而非项目这意味着删除实例后未绑定的浮动 IP、闲置卷、孤立安全组依然占着配额。定期执行下面三条命令把结果里的每条记录逐一确认后再释放# 找出 DOWN 状态、未被绑定的浮动 IP openstack floating ip list --status DOWN # 找出 available 状态、未被挂载的云硬盘 openstack volume list --status available # 找出 SHUTOFF 状态但仍在计费的实例 openstack server list --status SHUTOFF--status参数按资源状态筛选比人工逐条检查快得多。释放动作对应floating ip delete、volume delete和server delete删除前务必确认资源唯一引用——浮动 IP 释放后原地址无法找回可用卷里若还有数据先做快照再删。5.3 删除项目前的依赖顺序检查项目要整体清理时按依赖顺序操作顺序错了 Neutron 会报资源被占用。标准顺序解绑并删除浮动 IP删除实例从路由器摘除子网接口并删除路由器最后删除子网、网络和安全组。用一条命令验证端口是否完全清理# 列出项目下所有剩余端口正常清空后输出为空 openstack port list --project demo端口列表为空是网络层清理完成的标志。这个检查同样适用于日常排错实例删不掉时先看 port 列表里是否有 stuck 状态的端口手动删除后再删实例比反复重试删除命令有效得多。本文还有配套的精品资源点击获取