简介OpenStack超融合系统用户手册是针对HCS1000 G1系列超融合系统的官方操作指南面向数据中心运维人员、云计算管理员及系统架构师帮助用户掌握基于OpenStack平台的计算、存储、网络与虚拟化统一管理方法快速完成资源部署与日常运维。资源为单个docx文档大小2.58MB内容按系统简介、一键VPC、虚拟机、存储、网络、监控告警、自动化运维等章节编排涵盖登录退出、密码修改、资源配额管理、VPC创建与查看、虚拟机全生命周期操作、块存储与对象存储配置、虚拟网络及安全组设置等具体操作说明并附有安全合规方面的最佳实践。手册目录结构清晰步骤与界面指引详细用户可按需跳转查找操作方法既适合初次接触超融合架构的系统学习也可作为日常运维中的速查参考。目前已有317人学习下载对于正在部署或优化超融合环境的团队具有实用价值。1. OpenStack超融合为什么运维会为这份手册买单把 OpenStack 和超融合绑在一起听起来像是一套又重又复杂的组合拳。但凡是经历过传统虚拟化扩容的人都会懂这个场景计算节点不够了要加服务器存储不够了要加磁盘阵列网络要调整又得去改交换机配置一套环境下来采购周期长、排错路径长、扩容成本高。而 OpenStack 超融合系统本质上是把计算、存储、网络全部软件化跑在标准 x86 服务器上用分布式存储替代集中式存储用云平台 API 替代手工配置。今天这篇笔记就围绕这份《OpenStack超融合系统用户手册》背后的技术方案展开讲清楚这套东西的原理、最小落地路径、日常运维手法以及我踩过的那些坑。适合准备从传统虚拟化迁到开源云平台、或者正在纠结选型的人参考。2. 方案原理解析OpenStack 与超融合的分工与协同2.1 超融合的本质是存储不是虚拟化很多人提到超融合第一反应是“把虚拟化装进服务器里”。这个理解不能说错但没有触及核心。超融合真正的灵魂是分布式存储。以我们最常见的 Ceph 为例每一台参与超融合的服务器既跑虚拟化KVM又跑存储进程OSD多台服务器的本地硬盘通过以太网或 InfiniBand 网络聚合成一个统一的存储池。这个存储池对外提供块存储RBD、文件存储CephFS和对象存储S3 兼容接口。虚拟机镜像本质上存放在这个分布式存储池里计算节点宕机了虚拟机可以换一台机器继续跑因为数据不在本地。为什么说超融合的本质是存储因为计算虚拟化本身并不难KVM 加 libvirt 就能搞定难点在于把几十块甚至上百块硬盘组织成一个不丢数据、能扩容、性能稳定的存储系统。集中式存储时代这个活由磁盘阵列的控制器完成超融合时代这个活由每台服务器上的存储软件协作完成。理解了这一点再看 OpenStack 在其中的角色就清晰了——OpenStack 是控制平面负责“把存储池里的资源分配给虚拟机”这个过程。2.2 OpenStack 各组件在超融合里的职责边界OpenStack 本身不是一个大单体而是由十几个独立服务组成的框架。在超融合场景里真正核心的只有四个Nova计算服务、Neutron网络服务、Cinder块存储服务和 Glance镜像服务。Nova 负责创建、迁移、删除虚拟机它的底层调用 libvirt 去跟 KVM 交互同时通过驱动去对接存储后端。Cinder 负责卷的生命周期管理你创建一个数据盘挂给虚拟机走的就是 Cinder。Glance 负责镜像管理上传一个 ISO 或者 qcow2 镜像到 Glance后续建虚拟机才能选它做系统盘。还有一个隐蔽但必须提的组件是 Placement它负责记录每个计算节点上有多少可用资源CPU、内存、磁盘Nova 在创建虚拟机时根据 Placement 的数据选择目标节点。很多新手排错时忽略 Placement遇到“资源充足但虚拟机创建失败”的问题往往查半天其实看一眼 Placement 里上报的资源对不对就真相大白了。可以这样说OpenStack 是大脑Ceph 是肌肉两者通过驱动机制解耦理论上 Cinder 可以对接多种存储后端但超融合方案里 Ceph 几乎成了默认选择。2.3 为什么选 OpenStack 而不是深信服超融合平台拿深信服超融合平台来对比因为它是目前国内商业市场占有率最高的超融合产品之一网上相关讨论也最多。选型时本质上是在“开源的灵活可控”和“商业的省心省力”之间做权衡。深信服超融合平台的优势是界面友好、交付周期短、厂商技术兜底它的云管平台管理虚拟机、存储池、网络策略都是图形化操作普通运维一周内能上手。但劣势也明显底层是封装好的黑匣子出问题只能提工单而且扩容是绑定硬件品牌的换其他品牌服务器会有兼容性风险。选择 OpenStack 做超融合的团队通常是这么三类人一是已有 KVM 和 Linux 功底不想被商业产品绑定二是对网络有特殊需求Neutron 的灵活性远超商业产品三是预算敏感用通用 x86 服务器就能攒出一套环境。当然这条路需要自己扛稳定性出了问题得靠自己翻日志。我的建议是如果团队只有一两个人且没有 Linux 排障经验老老实实用商业方案如果能凑齐三四个能写脚本的运维OpenStack 超融合的长期成本会低很多。3. 从零搭建 OpenStack 超融合环境基于 packstack 的最小落地路径3.1 硬件规划三节点起步的参数基线很多人一上来就想搞五台七台的大集群但我建议第一步用三台机器起步。三台节点全部部署为控制节点兼计算节点兼存储节点这种 All-in-One 的部署方式虽然不推荐在生产环境长期使用但对于理解 OpenStack 超融合的运作机制、验证业务流程足够用了。生产环境的典型做法是三台控制节点独立部署高可用计算节点和存储节点按需扩展但初期验证不要贪多。硬件参数方面我给出一个通用基线每台服务器双路 CPU。一个常见误区是低估了内存需求。OpenStack 的各个服务组件加在一起轻松吃掉 16GB 内存Ceph 的 OSD 进程又要占用一定内存加上宿主机的系统开销一台 128GB 内存的服务器能用的虚拟机内存大概是 70GB 左右。所以说内存通道和容量尽量一步到位硬盘全部用 SSD 做 OSD 数据盘至少两块 NVMe 盘一块做系统盘部署宿主机操作系统另一块做 Ceph 的 WAL/DB 分区。如果预算紧张HDD 加 SSD 缓存盘也能跑但性能会打折扣。关于网络硬件的选择强烈建议至少万兆网络。超融合环境下虚拟机的 IO 全部走网络到达存储节点千兆网络在虚拟机数量超过十台后就会成为瓶颈。存储网络我建议单独设计至少要单独走一个物理网卡。三台服务器之间的存储网络最好是直连这样就可以减少一层交换机的转发延迟。3.2 网络规划管理网、业务网、存储网三张网怎么分网络规划是超融合方案里最容易被低估的环节也是后期故障率最高的环节。一个标准的超融合集群应该规划三张物理网络。管理网负责 SSH 登录、OpenStack API 请求、Horizon 界面访问IP 段如 192.168.10.0/24业务网负责虚拟机的外部网络流量也就是虚拟机和外部通信的通道IP 段如 192.168.20.0/24存储网负责 Ceph OSD 之间的数据复制和客户端 IOIP 段如 192.168.30.0/24。三个网络必须做隔离。物理上最彻底、最可靠的做法是把三个网络分配到三个不同的物理网卡上而不是用 VLAN 在一根网线上硬切。注意存储网络千万不能配置成带外管理口或者虚拟化平台共享的口否则 Ceph 的数据同步流量会严重挤占虚拟机业务带宽表现为“一到晚上备份时段虚拟机访问就卡得不行”。部署前的网络规划最好画一张拓扑图我的习惯是每台服务器给每张网卡配上固定标签避免插错线后去排查时晕头转向。OpenStack 中 Neutron 的 br-ex 桥接网卡必须绑定到业务网连接的那张物理网卡上这一点后面踩坑章会重点提到。3.3 基于 packstack 安装 OpenStack核心命令与参数说明RDO 社区提供的 packstack 工具是单节点或三节点快速部署 OpenStack 的最快路径。它本质上是把 Puppet 配置模块组合起来自动完成各组件的安装和配置。离线还是在线安装均可以但前提是操作系统必须为 RHEL 系如 CentOS Stream 或 Rocky LinuxDebian 系想要运行 packstack 过程会比较折腾。假设我们有三台服务器规划是第一台作为主控制节点另外两台加入即可。首先用 SSH 打通各节点之间的免密登录确保 packstack 能操作所有节点ssh-keygen -t rsa -b 4096 -N -f ~/.ssh/id_rsa ssh-copy-id rootnode1 ssh-copy-id rootnode2 ssh-copy-id rootnode3上面的命令会生成一对 SSH 密钥并分发到三台服务器上。-N 表示私钥不设置密码短语这是为了让后续自动化步骤无需人工干预。生产环境建议用专用的部署用户而不是 root但初学阶段 root 能减少不必要的权限排错。接下来安装 packstack以及编写应答文件dnf install -y centos-release-openstack-antelope dnf install -y openstack-packstack packstack --gen-answer-fileanswer.ini用--gen-answer-file生成应答文件。生成的这份 answer.ini 是 Packstack 部署的核心配置文件所有可调参数都在里面格式是 key-value 对相当于部署工作的总开关。关键参数说明如下表所示参数示例值含义CONFIG_CONTROLLER_HOST192.168.10.10控制节点 IPCONFIG_COMPUTE_HOSTS192.168.10.11,192.168.10.12计算节点列表CONFIG_NETWORK_TYPENEUTRON网络服务类型默认使用 NeutronCONFIG_NEUTRON_OVS_BRIDGE_IFACESbr-ex:eth1外部网桥映射CONFIG_CINDER_VOLUME_BACKENDceph块存储后端类型修改完参数后执行安装这一步耗时较长建议在 screen 或 tmux 里跑因为网络稍微波动或者下载包时间长了终端一断开进度就丢了packstack --answer-fileanswer.ini安装完成后屏幕上会输出一个 Horizon 访问地址和 admin 密码务必保存好接下来所有操作都依赖这个密码。packstack 的逻辑是先装控制节点上的数据库、消息队列、认证服务然后部署 Nova、Neutron、Cinder 等核心组件最后把计算节点和存储节点加入集群。如果中途失败看/var/log/packstack目录下的日志基本能定位到是网络不通还是包没装完。3.4 把 Ceph 接入 Nova 与 Cinder让虚拟机跑在分布式存储上packstack 默认安装的是本地存储后端也就是虚拟机镜像放在计算节点的本地磁盘上。我们需要把它改造成超融合形态把系统盘和数据盘都放到 Ceph 里这样虚拟机才能跨节点热迁移。首先在控制节点安装 Ceph 客户端dnf install -y ceph-common接着在 Cinder 的配置文件里指定 RBD 驱动和 Ceph 集群信息。在/etc/cinder/cinder.conf的[DEFAULT]段下面追加enabled_backends ceph volume_backend_name ceph创建 ceph 后端段落追加以下内容[ceph] volume_driver cinder.volume.drivers.rbd.RBDDriver rbd_pool volumes rbd_ceph_conf /etc/ceph/ceph.conf rbd_flatten_volume_from_snapshot false rbd_max_clone_depth 5 rbd_store_chunk_size 4 rados_connect_timeout -1这里rbd_pool参数指定 Ceph 中存储卷的池名称默认是 volumes。rbd_flatten_volume_from_snapshot false表示不强制展平克隆链能显著减少创建快照卷时的数据复制开销但代价是后续删除快照会变慢。rbd_store_chunk_size是条带化分块大小4 代表 4MB适合虚拟磁盘这种大块顺序 IO 比较多的工作负载。同时Nova 也要配置去 Ceph 里创建虚拟机的系统盘。修改/etc/nova/nova.conf[libvirt] images_type rbd images_rbd_pool vms images_rbd_ceph_conf /etc/ceph/ceph.conf rbd_user cinder rbd_secret_uuid 12345678-1234-1234-1234-123456789abcimages_type rbd使得 Nova 在创建虚拟机时直接把镜像写入 Ceph 的 vms 池并让迁移时不再需要镜像拷贝。需要配好rbd_secret_uuid它对应 libvirt 里 secret 的 UUID保存了 Ceph 的认证密钥。最后重启相关服务并验证 Ceph 里出现了虚拟机镜像systemctl restart openstack-nova-compute systemctl restart openstack-cinder-volume rbd ls vms输出里应该有uuid格式的镜像名说明 OpenStack 与 Ceph 已经成功对接超融合环境初步成型了。4. 日常运维手册巡检、备份、性能调优4.1 每日巡检看哪几个指标就够判断集群健康超融合系统最大的难点不是搭建而是长期运维。因为计算和存储在物理上耦合在一起一个节点的硬盘故障可能会导致整个集群的 IO 抖动。我日常巡检只看四个关键指标Ceph 集群的健康状态、OpenStack 服务状态、节点负载、存储 IO 延迟。Ceph 状态查询命令ceph -s ceph osd tree ceph osd dfceph -s输出中最关键的是health字段如果显示HEALTH_OK说明集群正常HEALTH_WARN说明有降级 PG数据副本数不足或者 OSD 空间快满了。ceph osd tree可以看到每个 OSD 是否在 up 和 in 状态。正常运行状态下所有 OSD 都是up且in。如果出现down或者out意味着有硬盘离线或触发了自动隔离机制。OpenStack 服务状态检查也很简单直接通过 nova-service-list 和 cinder-service-list 这两个命令行查openstack compute service list openstack volume service list每条服务记录有 State 字段up代表正常down代表异常。实际经验是 nova-compute 的服务状态最容易因为节点负载过高而误报为 down因为服务心跳检测的默认超时时间是 10 秒节点 CPU 跑满时心跳应答不过来会把存活服务误判为挂掉。看到 down 先别慌ssh 到对应节点看进程是否还在再查消息队列是否堆积最后再下结论。4.2 备份与恢复控制台数据库和配置文件的后悔药超融合环境里最要命的故障不是硬盘坏了而是控制节点的数据库损坏或配置文件被改错。OpenStack 的每个服务组件都有自己的数据库Nova、Neutron、Cinder 等都是独立库。好在 MariaDB 的备份逻辑并不复杂列一下我常用的备份脚本思路mysqldump -uroot -p密码 --all-databases /backup/openstack_all_$(date %F).sql cp -r /etc/keystone /backup/etc/keystone cp -r /etc/nova /backup/etc/nova cp -r /etc/neutron /backup/etc/neutron cp -r /etc/cinder /backup/etc/cinder以上命令表示把 OpenStack 各服务的配置目录和整个数据库备份到一个独立目录。恢复的时候先把数据库导回 MariaDB再恢复配置文件最后重启服务即可。但我必须强调配置文件备份比数据库备份更重要因为数据库是从配置文件读取连接信息的。假如只有数据库备份而没有配置备份恢复后各服务照样连不上库。另一个常被忽略的备份目标是 Ceph 的配置和 keyring 文件。/etc/ceph/目录下的ceph.conf和ceph.client.admin.keyring必须放进备份清单。丢了 keyring 就等于丢了整个集群的访问凭据所有客户端都得重新配认证。还有 Neutron 的数据库删除后虚拟机的网络配置会全部丢失这也是我需要特别提醒的。备份策略通常至少保留 7 天到 30 天每日全量备份加每日增量备份是比较稳妥的节奏。4.3 存储性能调优三个必调参数超融合环境里最常见的性能问题就是存储延迟高。虚机磁盘 IO 变慢表现为登录服务器卡顿、数据库查询慢、应用响应超时。当 Ceph 硬件没有瓶颈时最常见的优化手段有三处。第一处是 Ceph 的osd_memory_target参数。默认值通常是 4GB即每个 OSD 进程能使用的内存上限。如果服务器内存充裕大于 256GB建议调大到 8GBceph config set osd osd_memory_target 8589934592这样设置可以让 Ceph 在内存中缓存更多 IO 路径上的数据减少重复读盘。第二处是开启bluestore_min_alloc_size的 4K 对齐。Ceph 在 BlueStore 存储引擎下默认分配粒度是 64KBHDD或 4KBSSD如果跑的是数据库这种大量小写操作的负载小对象分配会成为瓶颈。对 NVMe 盘环境可以通过ceph config set调整为 4K具体参数名为bluestore_min_alloc_size_hdd和bluestore_min_alloc_size_ssdceph config set osd bluestore_min_alloc_size_ssd 4096第三处是网络层面需要确认 Ceph 公共网络和集群网络的网卡没有丢包。检查命令ip -s link show eth1输出的RX errors和TX errors如果持续增长说明网线或者交换机端口有问题。虚机 IO 延迟高时先排除网卡丢包再调存储参数顺序不要搞反。超融合的性能瓶颈很多时候不在硬盘而在网络路径。5. OpenStack 超融合踩坑手册五个高发问题实录5.1 虚拟机迁移后网卡丢包现象一台虚拟机从计算节点 A 热迁移到节点 B 后业务方反馈网络时断时续ping 丢包率在 10% 以上。原因节点 B 的物理网卡没有加入需要的外部网桥。Neutron 的网络桥接映射是每台计算节点独立配置的迁移前没有在所有计算节点上统一配置 br-ex 桥接。虚拟机迁移过去后虚拟网卡虽然存在但下游的物理出口路径没有打通。解决登录节点 B执行以下命令把物理网卡加入网桥再重启ovs-vsctl add-port br-ex eth1 systemctl restart openvswitch事后我在安装手册里新增了检查项部署完成后必须在每个计算节点上执行ovs-vsctl show确认 br-ex 的端口列表里包含物理网卡。热迁移是一个会被反复使用的功能任何节点新增都要同步网络配置。5.2 Ceph OSD 心跳超时导致集群异常现象某次机房断电恢复后ceph -s显示HEALTH_WARN部分 OSD 状态为down所有虚拟机 IO 卡死。原因机房 UPS 供电不稳导致多台服务器同时短暂掉电Ceph 的 OSD 进程启动速度不同步部分 OSD 超过mon_osd_down_out_interval设定的阈值默认 10 秒被自动标记为 out触发了集群级的 PG 重新分布瞬间拥塞了存储网络。解决先把 down 的 OSD 重新拉起并剔除 out 标记。如果确认硬盘本身没坏用ceph osd in把 OSD 重新加回集群然后等 PG 状态恢复正常。这个过程比较耗时PG 数量多的话可能需要几小时。教训是掉电场景不要慌着把所有 OSD 强行拉回先看监控数据确认没有硬件损坏再统一操作。如果 OSD 启动顺序不一会导致更多迁移风暴。5.3 控制节点重启后 Horizon 登录报错现象控制节点因为内核更新重启后访问 Horizon 页面弹出 503 或者直接连接被拒。原因三个服务没有随系统开机自启httpdWeb 服务、memcached缓存服务和 mariadb数据库。OpenStack 的 Horizon 依赖这三者同时在线任何一环没起来都会导致认证失败。解决systemctl enable --now httpd memcached mariadb systemctl restart openstack-keystone这次踩坑让我养成了习惯部署完后统一检查所有 OpenStack 相关服务的enabled状态用systemctl list-unit-files | grep openstack逐项核对。5.4 存储扩容后数据不均匀现象给集群新加了三台存储节点容量是有了但过了一周发现新节点的 OSD 使用率才 20%老节点已经 80%。原因Ceph 的 PG 自动重平衡优先级默认对已有数据不做大规模搬迁避免影响业务。新节点加入后PG 迁移是懒迁移只有当数据写入或已有 PG 被重新映射时才会缓慢地把数据分布过去。解决手动触发重平衡但要在低峰期操作ceph osd rebal on ceph osd set weight 0这里ceph osd rebal on的作用是打开自动重平衡开关。如果业务压力大还可以用ceph osd rebalanceon控制迁移速率。必须强调重平衡期间集群的额外 IO 开销会增大如果业务是不可中断的最好凌晨执行。5.5 Packstack 重装时残留配置干扰现象部署失败后删除环境重新用 packstack 部署结果提示端口被占用或者服务启动失败日志里报“Address already in use”。原因packstack 卸载时并不会完全清掉所有配置文件和服务自启项。上一次部署残留的 httpd 配置、MariaDB 的数据文件、libvirt 的网桥定义都在干扰新部署。解决重装前执行彻底清理systemctl stop openstack-* ceph-* 2/dev/null yum remove -y openstack-* ceph-* rm -rf /etc/openstack /etc/ceph /var/lib/mysql /var/lib/libvirt注意rm -rf是危险操作确认环境是实验环境后再执行。这个坑提醒我所有自动化部署工具都有“残留问题”生产环境的变更必须走配置管理工具比如 Ansible而不是反复跑 packstack。6. 进阶技巧把手册变成自动化巡检脚本6.1 用 OpenStack API 写健康检查脚本手册的价值不在于读而在于把里面写的东西变成每天自动执行的脚本。我后期做的最有价值的一件事就是把人工巡检流程代码化。OpenStack 提供了完整的 REST APIPython 的python-openstacksdk库封装了常用操作。下面这个脚本可以定时执行自动判断关键服务状态import openstack conn openstack.connect(clouddefault) services conn.identity.services() for service in services: print(f服务: {service.name}, 状态: {service.enabled}) computes list(conn.compute.services()) for svc in computes: if svc.state ! up or svc.status ! enabled: print(f[警告] 计算服务异常: {svc.binary}{svc.host})这里openstack.connect(clouddefault)读取的是/etc/openstack/clouds.yaml配置文件里的认证信息。专业用户可以直接用openstack命令行做同样的事但 Python 版本可以很方便地集成到 Zabbix 或 Prometheus 告警里。脚本跑在 cron 里每天 8 点执行一次任何服务状态异常都会在第一时间收到通知。6.2 用 crudini 批量管理配置文件超融合环境下少则有四五十个配置文件多则上百个。手动改配置容易遗漏。我推荐用crudini这个命令行工具来批量修改或检查配置crudini --get /etc/nova/nova.conf DEFAULT transport_url crudini --set /etc/cinder/cinder.conf DEFAULT enabled_backends cephcrudini --get可以快速确认某个配置项的当前值crudini --set则能实现脚本化的配置修改。搭配一个简单的遍历脚本就可以做到所有节点批量同步配置。我自己写过一个几十行的 shell 脚本把 nova.conf、cinder.conf、neutron.conf 里所有涉及后端存储的配置项汇总打印出来每次改动前先整体对比一遍避免改了这个节点忘了那个节点。这个习惯帮我挡住过好几次“改一台节点导致另外两台数据不一致”的翻车事故。做 OpenStack 超融合这三年多我最大的教训是这类系统不怕慢就怕乱。慢可以调优乱则会连锁故障。所有配置改动都留记录所有部署流程都写成脚本所有巡检项都自动化这也是为什么一份好的用户手册值得反复打磨。希望这些从实战里摔出来的经验能帮到你让你在这条路上少走几个来回。本文还有配套的精品资源点击获取