简介这份《OpenStack超融合系统用户手册》面向HCS1000 G1系列超融合系统的运维人员、数据中心管理员及云计算初学者用于指导用户通过OpenStack平台完成计算、存储、网络与虚拟化资源的统一管理与部署。手册围绕系统登录退出、密码修改、资源配额管理、一键VPC创建与查看等基础操作展开并延伸至虚拟机全生命周期管理、块存储与对象存储配置、虚拟网络与安全组策略、实时监控告警及自动化运维等模块同时给出安全合规方面的最佳实践建议。资源包共1个docx文档约2.58MB目录层级清晰按系统简介、一键VPC、虚拟机等章节组织便于按模块查阅。目前已有317人学习适合需要快速上手超融合平台、对照功能说明排查配置问题的读者参考。1. 从一份 docx 手册说起OpenStack 超融合系统到底能解决什么很多团队第一次接触私有云都是被一台台孤立的服务器逼出来的。业务要资源运维只能一台台装系统、配网络、挂存储交付周期按天算资源利用率却常年趴在 15% 以下。这份《OpenStack 超融合系统用户手册.docx》针对的正是这个场景把计算、存储、网络三层资源池化用一套 OpenStack 控制面统一调度让虚拟机、卷、网络在同一个集群里按需分配。它适合两类人——一类是准备从零搭一套内部云平台、又不想被商业方案绑死的运维工程师另一类是想搞懂超融合架构里 Ceph 与 Nova 怎么协同、Kolla 部署到底改了哪些参数的技术负责人。手册本身是文档型资源不是可执行代码包所以这篇笔记的重点放在「怎么照着文档把系统跑起来、参数怎么定、哪里最容易翻车」。2. 超融合架构拆解控制面、存储面、网络面怎么分工2.1 三个平面各管什么超融合的核心思路是把原本分散的存储设备收进计算节点用分布式存储软件OpenStack 生态里通常是 Ceph把每台机器的本地盘聚合成一个共享池。这样一台物理机同时承担计算和存储两个角色省掉了独立存储阵列的采购和运维成本。手册里描述的系统大致分三个平面控制面跑 Keystone、Nova API、Neutron Server、Glance、Horizon 这些无状态服务负责认证、调度、镜像管理。生产环境一般放 3 台做高可用。存储面Ceph MON 和 OSD 分布在计算节点上提供块存储对接 Cinder、对象存储对接 Swift 或 RGW、镜像存储对接 Glance。网络面管理网、存储网Ceph 后端流量、业务网虚拟机流量三张网物理隔离存储网建议万兆起步否则 Ceph 恢复时的回填流量会把业务网打满。理解这三个平面的边界后面看手册里的部署章节才不会迷路。很多新手一上来就照着命令敲结果网络平面没分清楚Ceph 集群建起来是通的一跑业务就超时。2.2 为什么选 Kolla 而不是手工装手册配套的部署方式从热词里的「openstack kolla」能看出大概率走的是 Kolla-Ansible 路线。手工装 OpenStack 的痛点是组件依赖太深Nova 一个版本升级可能牵动 oslo 系列十几个库不同节点版本漂移一点就起不来。Kolla 的做法是把每个服务打成容器镜像用 Ansible 统一编排节点之间只保证容器运行时和配置一致即可。常见做法是控制节点和计算节点都装 Docker或 PodmanKolla-Ansible 通过globals.yml一个文件控制几乎所有开关。这样升级时换镜像 tag、重跑 playbook 就行回滚也有后悔药。代价是你要接受容器网络这一层额外的复杂度排错时得同时看容器日志和 OpenStack 服务日志。2.3 部署前的资源规划表手册里如果给了硬件建议落地时最好按下面这张表核对一遍缺一项后面都可能卡住项目控制节点×3计算存储节点×N说明CPU8 核以上按虚拟机密度定计算节点要留核给 Ceph OSD内存32GB 起64GB 起Ceph OSD 每 TB 约需 1GB 内存做缓存系统盘240GB SSD240GB SSD别和数据盘混用数据盘无多块 SSD/HDD每块盘一个 OSD网卡2×万兆3×万兆管理/存储/业务分离提示存储网一定要独立Ceph 的public_network和cluster_network分开配否则业务流量和副本同步流量互相抢带宽延迟抖动会非常明显。3. 照着手册落地Kolla 部署的关键步骤与参数3.1 基础环境准备先在所有节点上做时间同步、主机名解析和防火墙放行。这几步看着琐碎但时间不同步会导致 Keystone token 校验失败主机名解析不对会让 RabbitMQ 集群起不来。# 所有节点统一时间源chrony 比 ntpd 更适合容器环境 dnf install -y chrony systemctl enable --now chronyd chronyc sources -v # 主机名解析控制节点和计算节点都要能互相解析 cat /etc/hosts EOF 192.168.10.11 ctrl01 192.168.10.12 ctrl02 192.168.10.13 ctrl03 192.168.20.21 comp01 192.168.20.22 comp02 EOF # 关闭 firewalld 或按手册放行端口Kolla 默认会自己管理 iptables systemctl disable --now firewalld逻辑说明chrony 负责时间同步chronyc sources用来确认上游时间源是否可达/etc/hosts里的 IP 要和后面globals.yml里的api_interface、storage_interface对应网段一致。参数上控制节点 IP 段和计算节点 IP 段建议分开方便后面按网段配防火墙规则。3.2 安装 Kolla-Ansible 并生成配置# 在部署节点通常是 ctrl01上操作 python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate pip install -U pip pip install ansible8 kolla-ansible # 生成全局配置和密码文件 kolla-genpwd mkdir -p /etc/kolla cp /opt/kolla-venv/share/kolla-ansible/etc_examples/kolla/globals.yml /etc/kolla/ cp /opt/kolla-venv/share/kolla-ansible/etc_examples/kolla/passwords.yml /etc/kolla/逻辑说明kolla-genpwd会往passwords.yml里填满随机密码包括数据库、RabbitMQ、Keystone 管理员密码。这一步千万别跳过手工设弱密码是后面被扫的高发点。ansible8是版本约束Kolla 对 Ansible 大版本比较敏感装最新版经常报模块找不到。3.3 globals.yml 里必须改的几项手册里如果只给了一份默认配置下面这几项是必须按实际环境改的改错任何一项部署都会中途失败# /etc/kolla/globals.yml 关键片段 kolla_base_distro: rocky # 基础镜像发行版要和宿主机匹配 kolla_install_type: source # source 或 binary生产建议 binary 更稳 openstack_release: 2023.2 # 版本号按手册给的来别自己跳版本 network_interface: ens192 # 管理网网卡名用 ip a 确认 api_interface: {{ network_interface }} storage_interface: ens224 # 存储网网卡Ceph 后端走这张 neutron_external_interface: ens256 # 业务/外部网网卡 kolla_internal_vip_address: 192.168.10.100 # 控制面 VIP enable_ceph: yes enable_cinder: yes enable_cinder_backend_lvm: no # 用 Ceph 做后端就关掉 LVM enable_neutron_provider_networks: yes逻辑说明network_interface和storage_interface必须对应真实存在的网卡名写错会导致容器起不来或 Ceph 无法通信。kolla_internal_vip_address是 HAProxy 对外暴露的虚拟 IP三台控制节点靠 keepalived 抢占这个 IP 不能和任何物理机冲突。enable_ceph打开后Kolla 会在计算节点上部署 Ceph 容器OSD 盘需要提前在ceph.yml或 inventory 里声明。3.4 引导部署与验证# 引导服务器安装依赖、配置 Docker kolla-ansible -i ./multinode bootstrap-servers # 部署前检查这一步能提前暴露大部分配置错误 kolla-ansible -i ./multinode prechecks # 正式部署耗时较长建议挂 tmux kolla-ansible -i ./multinode deploy # 部署后初始化 Keystone 里的项目、用户、网络 kolla-ansible -i ./multinode post-deploy逻辑说明bootstrap-servers负责装 Docker、配内核参数prechecks会检查端口占用、磁盘空间、网卡状态这一步报错一定要解决再往下走硬着头皮 deploy 只会浪费更多时间。post-deploy会生成/etc/kolla/admin-openrc.sh后面所有 OpenStack 命令都要先 source 这个文件。验证时先看容器状态再看服务 APIsource /etc/kolla/admin-openrc.sh openstack token issue # 能拿到 token 说明 Keystone 正常 openstack compute service list # 看 Nova 计算节点是否注册 openstack network agent list # 看 Neutron 各 agent 是否 alive ceph -s # 在 Ceph 容器里执行看集群健康状态注意openstack compute service list里如果计算节点是 down 状态先查 Nova 容器日志八成是消息队列连不上或虚拟化嵌套没开。4. 避坑与排查部署超融合最容易翻车的五个点4.1 Ceph OSD 起不来集群一直 HEALTH_WARN现象ceph -s显示 OSD 数量少于预期或者有 OSD 处于 down 状态。原因常见的是数据盘没做干净盘上残留了旧的 LVM 或文件系统签名Ceph 拒绝复用也可能是 OSD 容器没拿到足够的权限访问裸设备。解决先用lsblk确认盘没被挂载再ceph-volume lvm zap /dev/sdX --destroy清掉残留签名然后重新跑kolla-ansible deploy。如果是权限问题检查/etc/kolla/ceph-osd/下容器的启动参数里有没有--privileged。4.2 虚拟机创建成功但网络不通现象openstack server create返回 ACTIVE但 ping 不通控制台里看网卡没拿到 IP。原因Neutron 的 provider network 没配 VLAN 或扁平网络映射或者计算节点上的 OVS 网桥没把业务网卡桥进去。解决openstack network agent list确认 OVS agent 是 alive再看/etc/kolla/neutron-openvswitch-agent/里的openvswitch_agent.inibridge_mappings要和globals.yml里声明的物理网卡对应。改完配置重跑kolla-ansible -i multinode reconfigure -t neutron。4.3 部署到一半报 Docker 镜像拉取超时现象deploy阶段卡在 pulling image最后超时失败。原因默认镜像仓库在境外网络不稳定时拉取会中断。解决在globals.yml里配docker_registry指向内部镜像仓库或者提前用kolla-ansible pull把镜像拉到本地再 deploy。生产环境强烈建议自建 registry别每次部署都依赖外网。4.4 控制节点 VIP 漂移导致 API 间歇性不可用现象Horizon 偶尔打不开openstack命令时好时坏。原因keepalived 的 VIP 在三台控制节点之间反复抢占通常是网卡多播或防火墙把 VRRP 协议挡了。解决确认三台控制节点的管理网在同一个二层防火墙放行 VRRP协议号 112。ip a看 VIP 是否稳定停在某一台上如果来回跳检查keepalived容器日志里的优先级配置。4.5 存储网和业务网混用Ceph 回填拖垮业务现象业务高峰期虚拟机磁盘 IO 延迟飙升Ceph 出现 slow ops。原因public_network和cluster_network配成了同一张网卡副本同步流量和业务流量抢带宽。解决物理上分离两张网globals.yml里storage_interface指向独立网卡Ceph 配置里cluster_network单独指定网段。已经混用的至少用 QoS 限制 Ceph 后端流量但根治还是加网卡。5. 进阶技巧用 ceph osd tree 和 openstack hypervisor stats 做容量水位监控部署跑通只是开始超融合系统真正的运维难点在容量水位。Ceph 池用到 85% 以上性能会断崖式下跌Nova 计算节点内存超分太多会导致虚拟机集体卡顿。我一般会写一个巡检脚本把两个数据源拼在一起看。#!/bin/bash # 超融合容量水位巡检建议放 crontab 每小时跑一次 source /etc/kolla/admin-openrc.sh echo Ceph 集群状态 docker exec ceph-mon-ctrl01 ceph -s | grep -E health|osd|pg echo ----- OSD 使用率 ----- docker exec ceph-mon-ctrl01 ceph osd df tree | awk {print $1,$2,$NF} | head -20 echo Nova 计算节点水位 openstack hypervisor stats show -f value -c vcpus_used -c vcpus -c memory_mb_used -c memory_mb echo ----- 各节点虚拟机数 ----- openstack hypervisor list -f value -c Hypervisor Hostname -c Running VMs逻辑说明ceph osd df tree输出里最后一列是使用率百分比超过 80% 的 OSD 要重点关注必要时加盘或迁移 PG。openstack hypervisor stats show给出的是集群整体 vCPU 和内存的已用/总量vcpus_used/vcpus超过 0.8 就该考虑扩容计算节点了。这个脚本不解决任何问题但能让你在用户投诉之前先看到趋势。参数上Ceph 的mon_osd_full_ratio默认 0.95nearfull_ratio默认 0.85生产环境建议把 nearfull 调到 0.8留出更多缓冲。Nova 的cpu_allocation_ratio和ram_allocation_ratio在globals.yml里通过nova_cpu_allocation_ratio、nova_ram_allocation_ratio控制超融合节点因为还要跑 Ceph这两个值别设太高CPU 1:4、内存 1:1.5 是比较稳的起点。还有个容易忽略的点Glance 镜像存储如果也放在 Ceph 上镜像上传和虚拟机启动会共用同一套 OSD大批量创建虚拟机时 IO 会互相干扰。常见做法是给 Glance 单独建一个 pool并用rbd_cache参数做隔离。手册里如果没提这一层落地时自己补上能省掉后面很多性能投诉。从那以后我每次部署完超融合都会先跑一遍容量巡检脚本把 Ceph 和 Nova 的水位基线记下来再交给业务用。没有基线的系统出问题时你连「正常」是什么样都不知道。希望帮到你。本文还有配套的精品资源点击获取
)
