简介这份《OpenStack超融合系统用户手册》面向HCS1000 G1系列超融合系统的运维人员、数据中心管理员及云计算初学者用于指导用户通过OpenStack平台完成计算、存储、网络与虚拟化资源的统一管理与部署。手册围绕系统登录退出、密码修改、资源配额查看与申请等基础操作展开并重点讲解一键创建与查看VPC、虚拟机全生命周期管理、块存储与对象存储配置、虚拟网络与安全组策略、实时监控告警及自动化运维等核心模块同时给出安全合规与防火墙访问控制的最佳实践建议。资源包共1个docx文档约2.58MB目录层级清晰按系统简介、一键VPC、虚拟机等章节组织便于按需检索。目前已有317人学习下载适合需要快速上手超融合平台、对照功能模块查漏补缺的读者参考使用。1. OpenStack 超融合系统用户手册从裸机到可交付私有云的一条龙拆解很多团队第一次接触 OpenStack 超融合系统用户手册都是被一个很具体的场景逼出来的机房里有几台闲置的 x86 服务器本地插满了 NVMe 和 SATA 盘领导要求两周内交付一套能跑虚机、能挂块存储、能对接现有 LDAP 的私有云预算里没有独立 SAN 和万兆存储交换机。这时候超融合HCI就成了唯一现实的选择——把计算、存储、网络三件套压在同一批物理节点上用 Ceph 做分布式存储底座用 Kolla-Ansible 做容器化部署用 OpenStack 做资源编排入口。用户手册要解决的正是「这套东西装完之后日常怎么用、参数怎么调、坏了怎么修」的问题而不是再讲一遍 OpenStack 是什么。它适合已经决定走 Kolla 路线、节点数量在 3 到 12 台之间、需要一份能照着敲命令的运维参考的工程师。下面按「先立住架构判断再落到部署与调参最后收在排障技巧」的顺序展开中间所有命令和参数都可以直接抄。2. 超融合架构选型为什么是 Kolla Ceph 而不是别的组合2.1 三种主流部署形态的取舍逻辑在动手之前先把部署形态定下来否则后面每改一个参数都要返工。目前社区里能落地的 OpenStack 超融合方案基本收敛到三条路线纯 Kolla-Ansible 容器化、OpenStack CharmsJuju 编排、以及厂商发行版如基于 RDO 二次封装的商业版。用户手册里如果只写「安装 OpenStack」等于没说因为这三条路线的节点角色划分、存储接入方式、升级路径完全不同。Kolla-Ansible 的优势在于所有服务跑在 Docker/Podman 容器里配置集中在/etc/kolla下的 globals.yml 和各服务目录回滚和升级靠镜像 tag 切换对超融合这种「一台机器同时是计算节点和存储节点」的场景特别友好——你不需要为每个角色单独维护一套包依赖。Charms 更适合大规模、多租户、需要 MAAS 做裸机管理的环境学习曲线陡小团队容易翻车。厂商发行版省心但锁定严重用户手册里如果出现「联系厂商获取 license」这类句子基本可以判断它不适合自建。我一般会这样判断节点数 ≤ 12、团队有 Linux 和容器基础、需要自己掌控升级节奏选 Kolla-Ansible节点数 30、有专职 OpenStack 团队、需要和现有运维体系深度集成才考虑 Charms。超融合的核心矛盾是「存储和计算抢同一份 CPU 和内存」Kolla 的容器化让资源隔离和限额调整变得直观这是它在这个场景下胜出的关键原因。2.2 节点角色划分与最小硬件基线超融合不等于「所有节点完全一样」。即使用 Kolla也建议区分控制存储计算混合节点和纯计算存储节点。最小可用集群是 3 台因为 Ceph 的 MON 需要奇数个才能形成 quorum少于 3 台做超融合等于把可用性赌在单点上。下面这张表是我在多个项目里验证过的基线低于这个配置跑起来会非常痛苦角色节点数CPU内存系统盘数据盘网卡控制存储计算316 核64 GB480 GB SSD2×1.92 TB NVMe2×10GE纯计算存储3~932 核128 GB480 GB SSD4×1.92 TB NVMe2×10GE纯控制可选38 核32 GB240 GB SSD无2×10GE内存这一栏要特别说明Ceph OSD 每个进程大约吃 4 GBBlueStore 的 rocksdb 缓存还会额外占用64 GB 是「能跑」的下限不是「跑得好」的推荐值。如果虚机密度高128 GB 起步更稳。网卡必须双口一口走管理API一口走 Ceph 公共网络和集群网络生产环境建议再拆出存储前端网络避免虚机流量把 OSD 心跳挤掉。2.3 存储网络与 Ceph 公共网络的隔离原则超融合最容易出玄学问题的地方就是网络。Ceph 的 public network 承载客户端读写cluster network 承载 OSD 之间的数据复制和心跳这两者如果和 OpenStack API 网络混在一起会出现「虚机正常但存储间歇性卡顿」的现象看监控又找不到明显瓶颈。常见做法是至少划三个 VLAN管理网API、数据库、消息队列、存储公共网Ceph public、存储集群网Ceph cluster。如果物理网卡只有两个口就用 bond VLAN 子接口如果有四个口直接做两两 bond分别给管理和存储。Kolla 里通过api_interface、storage_interface、cluster_interface三个变量指定后面部署章节会给出具体写法。提示存储网络不要用 1GE。Ceph 在恢复时会打满带宽1GE 环境下一次 OSD 故障可能导致整个集群读写超时这是血泪经验。3. 用 Kolla-Ansible 在超融合节点上跑通最小集群3.1 基础环境准备与依赖安装先在所有节点上做统一的基础配置。以下命令在每台节点上执行假设操作系统是 Rocky Linux 9 或 Ubuntu 22.04两者步骤基本一致包管理器差异自行替换。# 关闭 firewalld 和 SELinux生产环境请改用精细规则这里为最小验证 systemctl disable --now firewalld setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config # 设置主机名与 hosts 解析三台节点分别设为 node1/node2/node3 hostnamectl set-hostname node1 cat /etc/hosts EOF 10.0.0.11 node1 10.0.0.12 node2 10.0.0.13 node3 EOF # 安装 Docker 与 Python 依赖 dnf install -y python3-devel libffi-devel gcc openssl-devel git python3-pip pip3 install -U pip pip3 install ansible6,8 kolla-ansible这段脚本做了四件事关掉会干扰容器网络的防火墙和 SELinux、统一主机名解析、装编译依赖、装 Kolla-Ansible 和它要求的 Ansible 版本。Ansible 版本必须卡在 6 到 8 之间太新会和 Kolla 的模块不兼容太旧缺少必要的 collection。/etc/hosts里的 IP 要换成你实际的规划地址三台节点必须能互相 ping 通主机名否则后面 Ceph 的 MON 发现会失败。3.2 globals.yml 里必须改的 12 个参数Kolla 的配置集中在/etc/kolla/globals.yml。复制示例文件后下面这些参数是超融合场景下必须逐条确认的漏一个都可能导致部署中断或存储不可用。# /etc/kolla/globals.yml 关键片段 kolla_base_distro: rocky openstack_release: 2023.2 # 选一个稳定版本不要用 master kolla_internal_vip_address: 10.0.0.10 network_interface: bond0 # 管理网 bond api_interface: bond0 storage_interface: bond1 # Ceph public 网 cluster_interface: bond1 # Ceph cluster 网小集群可复用 neutron_external_interface: bond0.100 # 外部网络 VLAN 子接口 enable_ceph: yes enable_ceph_mds: no enable_ceph_rgw: yes enable_cinder: yes enable_cinder_backend_ceph: yes enable_neutron_provider_networks: yes nova_compute_virt_type: kvm逐条说明openstack_release决定拉取哪个版本的容器镜像2023.2Bobcat在超融合场景下比较成熟kolla_internal_vip_address是 HAProxy 的 VIP必须是一个未被占用的地址且和节点同网段storage_interface和cluster_interface在小集群里可以复用同一张网卡但节点数超过 6 台后建议物理分离enable_ceph_rgw打开对象存储网关方便后续对接 S3 接口nova_compute_virt_type设为 kvm 才能用硬件加速如果嵌套虚拟化环境里跑改成 qemu性能会明显下降。3.3 生成密码文件与 Ceph 后端配置Kolla 用/etc/kolla/passwords.yml统一管理所有服务密码首次部署前必须生成。kolla-genpwd # 生成后检查关键密码是否为空 grep -E ^(ceph_|cinder_|nova_|neutron_) /etc/kolla/passwords.yml | head -20kolla-genpwd会为每个服务生成随机密码并写入文件。生成后要确认ceph_mon_key、cinder_rbd_secret_uuid这类字段不为空否则 Ceph 和 Cinder 对接时会报认证失败。如果后续要扩容节点这个文件必须保持一致建议纳入配置管理不要每次重新生成。接着配置 Ceph 的 OSD 设备发现。Kolla 支持自动发现但生产环境更推荐显式指定避免误把系统盘当数据盘。# /etc/kolla/config/ceph.conf [global] osd pool default size 3 osd pool default min size 2 osd pool default pg num 128 osd pool default pgp num 128 public network 10.0.1.0/24 cluster network 10.0.1.0/24osd pool default size 3表示每份数据存三副本这是 3 节点集群的最低要求min size 2表示至少两个副本可用时才允许写入防止脑裂时数据不一致PG 数量 128 适合 3 到 6 个 OSD 的小集群OSD 多了要按公式调整否则会触发too many PGs per OSD告警。3.4 执行部署与验证集群状态配置完成后按顺序执行引导和部署。整个过程视网络和磁盘速度3 节点大约 40 到 90 分钟。# 初始化 Ansible 环境 kolla-ansible -i /etc/kolla/inventory install python3-devel # 引导服务器安装 Docker 等基础组件 kolla-ansible -i /etc/kolla/inventory bootstrap-servers # 部署前检查会提示常见配置错误 kolla-ansible -i /etc/kolla/inventory prechecks # 正式部署 kolla-ansible -i /etc/kolla/inventory deploy # 生成 admin-openrc.sh kolla-ansible -i /etc/kolla/inventory post-deployprechecks这一步不要跳过它会检查 VIP 是否可达、接口是否存在、磁盘是否满足要求提前暴露问题比部署到一半失败再回滚省事得多。post-deploy会生成/etc/kolla/admin-openrc.sh里面包含 admin 用户的认证信息。部署完成后用下面几条命令验证核心组件source /etc/kolla/admin-openrc.sh openstack compute service list # 应看到所有 nova-compute 为 up openstack network agent list # neutron 各 agent 为 alive ceph -s # 在任意节点执行确认 HEALTH_OKceph -s输出里如果看到HEALTH_WARN且提示pgs not deep-scrubbed属于正常现象新集群还没触发深度擦洗如果提示osd down或mon quorum异常先查存储网络连通性再查 OSD 日志/var/log/ceph/。4. 超融合场景下的参数调优与日常运维动作4.1 Ceph 与 Nova 资源争抢时的调参顺序超融合最典型的性能问题是虚机 IO 一高Ceph 的 OSD 就来不及响应心跳导致 OSD 被标记为 down进而触发数据重平衡重平衡又进一步抢占资源形成恶性循环。调参要按「先限制 Nova再限制 Ceph最后调内核」的顺序来。第一步限制单台计算节点上的虚机密度和 CPU 超分比。在/etc/kolla/config/nova/nova-compute.conf里[DEFAULT] cpu_allocation_ratio 4.0 ram_allocation_ratio 1.0 disk_allocation_ratio 1.0 reserved_host_memory_mb 8192cpu_allocation_ratio 4.0表示 16 核物理 CPU 最多分配 64 vCPU超融合场景不建议超过 4否则 CPU 争抢会拖慢 Ceph 的线程ram_allocation_ratio 1.0表示不做内存超分因为 Ceph OSD 本身吃内存再超分容易触发 OOMreserved_host_memory_mb给宿主机留 8 GB保护 OSD 和容器运行时。第二步限制 Ceph 的恢复和回填速度避免故障后恢复流量打满网络。在/etc/kolla/config/ceph.conf追加[osd] osd_recovery_max_active 2 osd_max_backfills 1 osd_recovery_op_priority 2 osd_client_op_priority 63这几个参数的含义是同时最多 2 个恢复操作、最多 1 个回填、恢复优先级低于客户端读写。代价是故障后恢复时间变长但换来的是业务虚机在恢复期间仍能正常响应。如果集群负载很轻可以适当调高但不要超过osd_recovery_max_active 4。第三步调整内核的脏页回写参数减少突发 IO 对 OSD 的冲击# 在每台存储节点执行写入 /etc/sysctl.d/99-ceph.conf 持久化 vm.dirty_ratio 10 vm.dirty_background_ratio 5 vm.swappiness 1vm.dirty_ratio从默认 20 降到 10让内核更早开始回写避免一次性刷大量脏页vm.swappiness 1尽量不用 swap因为 OSD 进程被换出后再换入会引发严重延迟。4.2 虚机创建到块存储挂载的完整链路验证参数调完之后要用一条完整的业务链路验证而不是只看服务列表。下面从创建网络、上传镜像、创建虚机、挂载卷走一遍。source /etc/kolla/admin-openrc.sh # 创建外部网络和租户网络 openstack network create --external --provider-physical-network physnet1 \ --provider-network-type flat public openstack subnet create --network public --subnet-range 192.168.100.0/24 \ --gateway 192.168.100.1 --no-dhcp public-subnet openstack network create private openstack subnet create --network private --subnet-range 10.10.0.0/24 \ --gateway 10.10.0.1 --dns-nameserver 223.5.5.5 private-subnet openstack router create router1 openstack router set router1 --external-gateway public openstack router add subnet router1 private-subnet # 上传镜像并创建虚机 openstack image create --disk-format qcow2 --container-format bare \ --file cirros-0.6.2-x86_64-disk.img cirros openstack flavor create --vcpus 2 --ram 2048 --disk 10 small openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey openstack server create --flavor small --image cirros --network private \ --key-name mykey test-vm # 创建卷并挂载 openstack volume create --size 20 test-vol openstack server add volume test-vm test-vol这段脚本覆盖了 Neutron 的 provider 网络和租户网络、Router 的 NAT、Glance 镜像、Nova 调度、Cinder 卷创建与挂载。执行后重点看两个地方openstack server list里虚机状态是否为 ACTIVEopenstack volume list里卷是否从 creating 变为 available 再变为 in-use。如果卷一直卡在 creating去 Cinder 的卷服务日志里找rbd相关报错通常是 Ceph 认证或 pool 不存在。4.3 扩容节点时的标准动作与数据重平衡观察超融合集群扩容不是插上机器跑一遍 deploy 就完事。新节点加入后Ceph 会自动开始数据重平衡这时候如果直接投入生产老节点的 IO 会被重平衡流量拖垮。标准动作是先加节点、再限制重平衡速度、观察ceph -s直到activeclean、最后恢复参数。具体命令# 在新节点上执行 bootstrap 和 prechecks 后只部署新节点 kolla-ansible -i /etc/kolla/inventory deploy --limit newnode # 加入 Ceph 集群后临时限制重平衡 ceph osd set norebalance ceph osd set norecover # 观察当前 PG 状态 ceph -s # 确认业务低峰期后逐步放开 ceph osd unset norebalance ceph osd unset norecover--limit newnode让 Kolla 只对新节点操作避免影响已有节点上的容器。norebalance和norecover是 Ceph 的全局标志设置后新数据仍可写入但不会主动迁移已有 PG。观察ceph -s里的pgs数量和misplaced比例等业务低峰再放开通常选择凌晨执行。5. 用户手册里最容易翻车的五个坑5.1 坑一VIP 地址冲突导致 API 间歇性不可达现象openstack命令时好时坏HAProxy 日志里出现Connection refused但三个节点上的 keepalived 都显示 MASTER 或 BACKUP 正常。原因kolla_internal_vip_address配了一个和现有设备冲突的 IP或者 VIP 和节点不在同一二层网络keepalived 的 VRRP 通告收不到。超融合环境里经常把 VIP 配到存储网段而存储网段没跑 VRRP。解决把 VIP 放在管理网用arping -I bond0 10.0.0.10确认没有其他设备响应检查ip a里 VIP 是否只出现在一个节点上如果用了 bond确认 bond 的fail_over_mac参数不会导致 VRRP 源 MAC 变化。5.2 坑二OSD 被误判为 down 触发全量恢复现象业务高峰期突然收到osd down告警随后ceph -s显示大量 PG 处于activerecovery虚机 IO 延迟飙升。原因OSD 心跳超时默认 20 秒超融合节点上 CPU 被虚机占满时OSD 线程调度不及时心跳包发不出去MON 就认为 OSD 挂了。等 CPU 缓过来OSD 重新上线又触发一轮恢复。解决把osd_heartbeat_grace从默认 20 调到 60给 OSD 更多喘息时间同时按 4.1 节限制 CPU 超分比。如果已经发生先ceph osd set norecover止血再排查是哪个虚机在抢 CPU。5.3 坑三Cinder 卷创建卡在 creating 且无明确报错现象openstack volume create后卷状态一直停在 creatingCinder API 日志只有一行Unable to create volume没有堆栈。原因Cinder 的 Ceph 后端配置里rbd_secret_uuid和ceph.client.cinder.keyring不匹配或者 pool 没提前创建。Kolla 默认会自动建 pool但如果enable_cinder_backend_ceph开了而ceph相关密码在 passwords.yml 里为空就会静默失败。解决检查/etc/kolla/cinder/cinder-volume.conf里的rbd_pool、rbd_user、rbd_secret_uuid三项在 Ceph 节点执行ceph auth get client.cinder确认 keyring 存在手动ceph osd pool create volumes 128和ceph osd pool create images 128后重试。5.4 坑四Neutron 外部网络不通但虚机内部正常现象虚机之间能互 ping虚机能 ping 通网关但 ping 不通外部物理网络浮动 IP 也绑不上。原因neutron_external_interface指定的接口没有放行 VLAN或者物理交换机端口没配 trunk。超融合环境里经常把外部网络和存储网络混在同一张网卡的不同 VLAN交换机侧漏配一个 VLAN 就断。解决在计算节点上tcpdump -i bond0.100 -n看是否有 ARP 请求发出检查交换机端口是否允许该 VLAN确认neutron_external_interface写的是子接口名而不是父接口名。5.5 坑五升级 Kolla 镜像后容器反复重启现象执行kolla-ansible upgrade后部分容器状态在restarting和running之间循环日志里出现数据库 schema 不匹配。原因跳版本升级比如从 2023.1 直接到 2024.1中间缺少数据库迁移步骤或者openstack_release改了但kolla_base_distro没同步改镜像基础系统不一致。解决严格按版本顺序升级每次只升一个 release升级前备份数据库确认kolla_base_distro和openstack_release的组合在官方支持矩阵里。如果已经卡住回滚到旧镜像 tag先恢复业务再排查。6. 把用户手册变成可执行检查单的一个技巧写到这里部署、调参、排障的主线已经走完。最后分享一个我用了很久的习惯不要试图维护一份「大而全」的用户手册而是把它拆成三份可执行的检查单——部署前检查单、日常巡检检查单、故障恢复检查单。部署前检查单就是第 3 章里那些 prechecks 命令加上硬件基线表日常巡检检查单是每天早上跑一遍ceph -s、openstack compute service list、openstack network agent list把输出贴到值班记录里故障恢复检查单则把第 5 章的五个坑对应的止血命令写成脚本出事时直接执行不靠记忆。这个技巧的关键在于用户手册的价值不在于写得多全而在于出事时能不能在五分钟内找到那条命令。我见过太多团队把手册写成架构文档结果 OSD 一 down 还是手忙脚乱。把命令按场景固化下来比任何原理描述都管用。希望帮到你。本文还有配套的精品资源点击获取