★ FEATURED ARTICLE 简介OpenStack超融合系统用户手册是一份围绕HCS1000 G1系列超融合系统展开的操作指南目标读者是数据中心运维人员、云计算平台管理员以及刚接触OpenStack的入门用户。手册从最基础的登录/退出和密码管理讲起包含账号密码修改、忘记密码找回、资源配额的查看与申请流程随后进入一键VPC功能指导用户快速创建隔离网络、自定义网络拓扑和安全策略并随时查看VPC状态在虚拟机部分详细列出创建、启动、停止、迁移和删除等生命周期操作存储部分则覆盖块存储与对象存储的卷管理、容量扩展及备份策略网络管理涉及路由器、子网和安全组配置此外还包括资源实时监控与告警、自动化部署与故障恢复以及强密码、防火墙规则等安全合规建议。资源包内仅含1个docx文档约2.58MB目录按系统简介、VPC、虚拟机、存储、网络等模块组织方便对照查阅。已有317人学习下载适合作为超融合环境下OpenStack平台的操作备查手册和团队培训参考资料。1. OpenStack超融合系统到底是什么三台物理机怎么撑起一套私有云OpenStack 超融合系统并不是 OpenStack 项目手册里的官方名词而是厂商把控制节点、计算节点和存储节点合并到同一批物理机之后形成的交付形态。你拿到这份 .docx 用户手册多半是团队刚采购或准备自建私有云手头只有几台服务器却想同时跑出虚拟机、块存储和对象存储。超融合解决的正是这个矛盾用副本代替 RAID 卡兜底把 SAN 存储换成软件定义存储让控制、计算、存储三类角色共享 CPU 与磁盘。适合谁适合不想单独养存储阵列、又需要快速交付云主机的中小团队也适合做 OpenStack 云平台搭建验证的技术人员。这篇笔记按三节点起步来写覆盖部署、初始化、备份和排障并把手册里普遍写得很含蓄的坑单独拉出来。2. 为什么三节点超融合能交付虚拟机控制合设与 Ceph 存储的关键关系2.1 控制平面与数据平面先搞懂控制节点要扛多少东西OpenStack 本质是一组无状态 API 服务加上一堆有状态后端keystone 负责认证nova 负责计算neutron 负责网络cinder 负责块存储glance 负责镜像。超融合架构里这几类角色不再分机器部署而是把控制组件集中到一台或两台机器上。三节点场景最常见的布局是 1 控 2 算第 1 台跑控制平面全部服务第 2、3 台跑 nova-compute 与分布式存储 OSD。控制节点上要同时跑 mariadb、rabbitmq、keystone、nova-api、nova-scheduler、nova-conductor、neutron-server、cinder-api、glance-api 以及 horizon这些进程平时 CPU 占用不高但 API 请求一多最先撑不住的不是计算资源而是数据库连接和消息队列堆积。所以控制节点的内存规划要比计算节点更宽裕。我一般建议控制节点 64G 起步计算存储节点 128G 起步因为每台节点上跑多个 OSD 时page cache 会吃掉大量内存。如果控制节点内存只有 16G你创建一个云主机时还不觉得有什么一旦批量创建 30 台虚拟机nova-scheduler 调度、cinder 建卷、neutron 分配网段同时涌进来mariadb 的连接数会先被打满表现为创建任务卡在 BUILD 状态不更新。2.2 Ceph 在超融合里的角色glance、cinder 与 nova 共用一个存储池超融合与传统 OpenStack 最大的区别在存储底座。传统架构里镜像放 NFS 或集中式存储虚拟机磁盘放本地 RAID块设备走 SAN超融合则用 Ceph 把这三种数据统一到一套分布式存储里。Ceph 提供 RBD 块设备glance 把镜像文件写入 images 池cinder 把卷放在 volumes 池nova 创建云主机时如果需要临时盘也可以直接写在 vms 池。三个池共用同一批 OSD但池之间通过 pg 数量、副本数独立管理。这套设计带来的好处是计算节点本身不需要大容量本地盘所有数据都能在节点间漂移代价是网络压力翻倍因为每次写数据都要把副本复制到其他节点。这里有个新手常忽略的容量账。Ceph 默认三副本一份数据写三份一个 10T 的集群可用空间只有 3.3T 左右。不少人在采购时按原始容量算存储上线一个月后发现空间告急才回来改副本数。超融合场景下三副本是保证数据可靠性的底线两副本通常只允许在测试环境用。你可以通过 CRUSH map 调整规则但生产环境不建议为了容量牺牲副本数。2.3 硬件选型的容量账按副本数算一遍你真正可用的空间三节点超融合的硬件选型重点不在品牌而在参数匹配。管理网千兆即可业务网和存储网最好 25G 起存储网络用万兆是底线否则多节点同时写盘时网络会成为整条链路的瓶颈。组件配置参考如下表按三节点、每节点 4 块 4T SATA 盘加 2 块 480G SSD 来举例节点角色CPU内存系统盘数据盘网卡控制节点双路 8 核64G480G SSD x 2可选 4T x 21G 管理 25G 存储/业务计算存储节点双路 16 核128G480G SSD x 24T x 41G 管理 25G 存储/业务容量计算公式可以写为可用容量 单盘容量 x 盘数 x 节点数 x (1 / 副本数) x (1 - 预留余量)预留余量通常取 0.1用于重均衡和故障域切换。按上表三节点 12 块 4T 盘计算原始容量约 48T三副本后折到 16T再扣 10% 预留实际可用约 14.4T。这笔账必须在采购前算清楚否则后续扩容要加盘导致整个集群的 CRUSH map 重新调整操作成本很高。3. 用 PackStack 搭建 OpenStack 云平台的最小路径从应答文件到第一台云主机3.1 部署前必须完成的网络规划与主机名解析基于 PackStack 安装 OpenStack 是社区里最常见的快速部署方式适合实验室验证和小规模交付。它本质上是把各个 OpenStack 组件的服务编排成一批 Puppet 配置自动去装包、改配置、初始化数据库。注意 PackStack 不是生产环境高可用方案的替代品它默认生成的架构是单控制节点。部署前要先把网络分区定死。每个节点至少两张网卡一张走管理网络承载 SSH、API、数据库和消息队列流量另一张走业务网络承载云主机流量。如果条件允许存储流量单独拆一张 25G 网卡不要跟业务网络混跑。混跑的问题当时不明显但只要你开始做快照或批量创建卷存储流量瞬间占满带宽业务虚机就会出现卡顿。主机名解析是另一个容易踩的地方。OpenStack 各组件间通信频繁走主机名而不是 IP。我在所有节点上都会配好 /etc/hosts把三台机器的主机名和 IP 都写进去并且保证 hostname -f、hostname -s 的输出与 hosts 一致。不要依赖 DNS 服务器因为 OpenStack 服务启动时查询 DNS 失败会表现为服务起来了但互相连不上。3.2 生成应答文件并调整参数交给 PackStack 之前先想清楚这几项PackStack 的典型操作是先让工具给你生成一份应答文件然后人工改关键项。生成命令如下# 在规划为控制节点的机器上执行生成应答文件 packstack --gen-answer-file/root/answers.txt生成的 answers.txt 有几百行不要全改只需要关注几类字段计算节点列表、网络节点列表、Ceph 安装开关、Cinder 后端类型。我把最小三节点超融合场景下的关键修改项列出来# 应答文件关键参数说明字段在不同版本里小有差异 CONFIG_COMPUTE_HOSTS192.168.1.11,192.168.1.12,192.168.1.13 # 三个节点既当计算节点也准备作为超融合存储节点的一部分 CONFIG_NETWORK_HOSTS192.168.1.11 # 网络代理服务集中在控制节点避免多节点竞争 DHCP 地址池 CONFIG_CEPH_INSTALLy # 启用 Ceph才能让 glance/cinder/nova 使用 RBD 后端 CONFIG_CINDER_BACKENDceph # 明确 Cinder 后端走 Ceph 驱动这里 CONFIG_COMPUTE_HOSTS 填三台节点意味着每台都安装 nova-computeCONFIG_NETWORK_HOSTS 只填控制节点是为了避免 neutron 的 DHCP 和 L3 服务在多个节点上冲突。Ceph 安装开关打开后PackStack 会一并完成 Ceph 监控节点和 OSD 的初始化。改完后执行安装# 按应答文件安装时间较长建议用 nohup 或 tmux 保持会话 packstack --answer-file/root/answers.txt 21 | tee /root/packstack.log执行过程中不要手动去 apt/yum 其他包。日志文件里出现 “ID: ... SUCCESS” 字样说明对应步骤完成如果出现 FAIL直接去查日志中标注的模块名。PackStack 的幂等性做得一般失败后直接重跑常常会撞上残留的数据库或配置更可靠的做法是看日志定位具体失败的组件卸载该组件的包再继续。3.3 云主机创建五连镜像、网络、子网、虚拟机、数据卷安装完成后会生成一个 /root/keystonerc_admin 文件。source 它之后命令行就能直接调用 OpenStack API。创建第一台云主机的路线通常是镜像、网络、子网、虚拟机、数据卷五步# 加载管理员环境变量 source /root/keystonerc_admin # 上传一个小体积测试镜像qcow2 格式最省空间 openstack image create --file ./cirros.qcow2 --disk-format qcow2 \ --container-format bare --public cirros # 创建 Flat 类型的物理网络physnet1 对应业务网卡名称 openstack network create --provider-network-type flat \ --provider-physical-network physnet1 flat-net # 给网络划分一个子网DNS 按实际环境填 openstack subnet create --network flat-net --subnet-range 10.10.0.0/24 \ --dns-nameserver 114.114.114.114 --gateway 10.10.0.1 flat-subnet # 创建云主机使用 2C4G 规格固定到 flat-net openstack server create --flavor m1.small --image cirros \ --network flat-net test-vm # 创建一块 10G 数据卷并挂载到云主机上 openstack volume create --size 10 test-vol openstack server add volume test-vm test-vol这段操作的逻辑是先把镜像注册进 glance然后让 neutron 准备好二层网络最后通过 nova 调度把虚拟机制造出来。挂卷这一步验证了 Ceph 后端是否真正生效如果卷创建后一直卡在 creating说明 cinder-volume 到 Ceph 的认证或网络不通需要回到 cinder.conf 检查 rbd 相关配置。打开 Dashboard 之后用 admin 账号登录能看到镜像、网络和云主机的状态。如果这三个界面都能正常显示数据说明这套最小超融合已经具备交付云主机的基本能力。4. 日常备份与故障恢复顺序控制节点挂了先救这三样4.1 数据库层的五库逻辑备份直接决定你能不能恢复OpenStack 超融合系统里最脆弱的不是计算进程而是数据库。keystone、nova、neutron、cinder、glance 各有一套数据库里面存着用户、项目、镜像元数据、虚拟网卡和卷信息。节点宕机后服务可以重装但这些数据库丢了整个平台等于失忆。我习惯每天做一次逻辑备份用 mysqldump 导 SQL 文件而不是直接拷贝数据目录。物理拷贝虽然快但需要停库或使用文件系统快照在控制节点上做不到不停机。逻辑备份命令如下# 循环备份五个核心库密码由环境变量 MYSQL_PWD 提供 for db in keystone nova neutron cinder glance; do mysqldump --single-transaction --set-gtid-purgedOFF \ --databases $db /backup/$(date %F)-${db}.sql done--single-transaction 参数保证备份期间不锁表控制节点可以继续对外服务--set-gtid-purgedOFF 是为了让 SQL 文件在任意 MySQL/MariaDB 实例上都能导入恢复不会携带源库的 GTID 历史。备份文件至少要保留 7 天并复制到控制节点以外的位置。只备份在控制节点本地节点磁盘故障时备份也会一起消失这就失去了备份意义。4.2 配置与密钥资产别等 erlang cookie 丢了才后悔OpenStack 各组件间的认证除了 Keystone 的 token还有一堆本地密钥和配置rabbitmq 的 erlang cookie、nova 的 /etc/nova/nova.conf、neutron 的 /etc/neutron/neutron.conf、Ceph 的 /etc/ceph/ceph.client.admin.keyring。这些文件不占空间但重建成本极高。erlang cookie 不一致会导致 rabbitmq 集群节点互相拒绝连接而重新生成 cookie 需要重启整个消息队列并重建所有镜像队列。Ceph 的 admin keyring 一旦丢失ceph 命令都无法执行只能通过 mon 节点手动恢复权限。备份命令并不复杂# 打包所有关键配置文件按日期归档 tar czf /backup/$(date %F)-openstack-conf.tar.gz \ /etc/keystone /etc/glance /etc/nova /etc/neutron /etc/cinder \ /etc/ceph /var/lib/rabbitmq/.erlang.cookie这包文件配合 4.1 的数据库备份足以在一台全新的控制节点上把整个控制平面恢复回来。恢复顺序是先装好基础包再解压配置导入数据库最后逐个启动服务。不要先把服务拉起来再改配置那样会有很多互相等待的报错。4.3 节点宕机后的恢复观察先用 ceph -s 判断存储自愈状态超融合环境里计算节点宕机后系统会自动把虚拟机调度到其他节点但前提是底层存储状态健康。节点恢复开机后不要急着起虚拟机先在任意节点执行# 查看 Ceph 集群整体健康状态 ceph -s关注输出里的 health 字段和 pgs 状态。正常情况 HEALTH_OK如果有 PG 处于 peering 或 degraded说明数据正在自愈这时候创建的虚拟机盘可能会卡在等待状态。等所有 PG 回到 activeclean 再批量启动云主机才是可靠的做法。这套观察方法也适用于控制节点重启后的场景。控制节点上的 mon 和 OSD 如果不在线Ceph 集群多数情况下还能继续对外服务但一旦超过一半 mon 失联就会出现 quorum 丢失所有读写都会被挂起。遇到这种情况先检查三个 mon 进程是否都活着再看端口 6789 和 3300 能不能互通时间同步服务是否异常。5. OpenStack 超融合最容易翻车的 5 个错误操作现象、原因与解决5.1 虚拟机制建失败状态卡在 ERROR现象创建云主机后状态一直是 ERROR点进详情看不到任何 IP。原因最常见的是 nova-compute 无法连接 libvirt。要么是 CPU 虚拟化没开要么是 /etc/libvirt/libvirtd.conf 的监听配置不对也有可能是 qemu-system-x86 包没装。解决先在计算节点执行 virt-host-validate 看虚拟化是否就绪然后检查 /var/log/nova/nova-compute.log 里是否有 “Cannot connect to libvirt” 字样。如果宿主机的 BIOS 里虚拟化功能没开任何 OpenStack 配置都无法绕过必须重启机器进 BIOS 开启 Intel VT 或 AMD SVM。5.2 Ceph 的 PG 一直 peering块存储不可用现象ceph -s 显示 HEALTH_WARN大量 PG 状态是 peering 或 inactive创建云主机时卷无法挂载。原因多数情况和网络抖动、时钟漂移有关。Ceph 对节点间时间偏差要求很严偏差超过阈值OSD 之间的心跳和日志会持续告警另外防火墙只放开了管理网口没有放行 6789/3300 端口也会导致 PG 无法完成 peering。解决在每台节点上配置 chrony 指向同一时间源然后确认防火墙放行 Ceph 的端口。如果 PG 已经处于异常状态超过 10 分钟可以考虑重启对应 OSD 进程注意不要同时重启多个 OSD防止集群长时间不可用。5.3 控制节点重启后消息队列无法拉起现象控制节点断电重启后rabbitmq-server 服务一直处于 activating 状态DashBoard 登录报“503 Service Unavailable”。原因消息队列的数据目录和 erlang cookie 出现了不一致。如果是单控制节点最常见的原因是 rabbitmq 未配置开机自启或者数据目录在断电时写入不完整。解决先用 systemctl status rabbitmq-server 查看具体报错如果确认是 cookie 不被识别从备份里恢复 /var/lib/rabbitmq/.erlang.cookie然后重启服务。这里提醒一点平时不检查开机自启列表到故障时才发现 rabbitmq 根本没有 enable这属于管理盲区。5.4 PackStack 中途失败后重复安装冲突现象PackStack 安装 neutron 时报错失败清理后重跑报“某个组件已存在”或者数据库表重复。原因PackStack 执行到一半时已经创建了 neutron 数据库、装了一半的包甚至已经写了一部分 /etc/neutron 配置直接重跑会和现有残留冲突。解决不要盲目重跑。先用 packstack --answer-file 重新生成一份干净应答文件把已经失败的组件相关的安装项关闭等成功后再单独补装。或者干脆把相关组件的包卸载、清理 /var/lib/puppet 和对应数据库再从头来一遍。这个过程我一般保留原始 log按日志一条条核对比反复试错快得多。5.5 Dashboard 显示不出云主机列表全是报错现象登录 Horizon 后项目概览页无法显示实例列表页面报 “Unable to retrieve instance list” 之类错误。原因Horizon 到 Nova API 的认证或 endpoint 地址出了问题。常见场景是控制节点 IP 发生过变更keystone 里的 endpoint 还记录着旧地址或者 nova-api 服务没起来。解决先在命令行执行 openstack endpoint list对照 nova 的 endpoint 看 public/admin/internal 地址是否都指向当前控制节点 IP。如果地址不对用 openstack endpoint set 修正如果服务进程本身挂了systemctl restart nova-api再看 /var/log/nova/nova-api.log。6. 验收超融合系统的自测方法把冒烟测试做成一条命令超融合系统交付时最怕验收只停留在“能创建一台虚拟机”。我每次做完部署都会用一组命令做冒烟测试覆盖镜像、网络、卷、关键服务状态和开机自启验证完再交接给业务部门。# 来源环境变量后依次验证 API、卷操作、关键服务状态 source /root/keystonerc_admin # 验证 keystone 认证链路 openstack service list /dev/null echo keystone OK # 验证 cinder 到 Ceph 的连通链路建一块卷再删除 openstack volume create --size 1 smoke-vol sleep 5 openstack volume delete smoke-vol echo volume OK # 检查控制节点关键服务是否在运行并已设置开机自启 systemctl is-active mariadb rabbitmq-server httpd systemctl is-enabled mariadb rabbitmq-server httpd /dev/null echo auto-start OK这段脚本的逻辑是service list 能返回数据说明 keystone、数据库、API 层整个链条通卷创建删除成功说明 cinder 到 Ceph 的读写通路没问题systemctl is-enabled 检查的是重启后服务能不能自己回来。我早期吃过一个亏当时只验证了“能建虚拟机”没有验证“控制节点重启后服务自动拉起”。后来一次控制节点断电机器起来后 nova-api 没启动平台整个黑匣子一样没有任何提示恢复时间被拉长到半天。从那以后我的验收清单里永远会加一条重启测试把三台节点依次重启再执行一遍上面的冒烟脚本。超融合这种架构服务编排链路很长任何一个进程没起来API 都会报错但日志位置各不相同排查成本很高。宁可把验证做细也不要把问题留给夜里值班的同事。希望帮你提前把这些坑排掉。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
