我从来没觉得“看官方文档”不重要但OpenStack这类项目的官方文档默认你手里已经有一套标准环境文档写再细也来不及解释“为什么答案文件里这一项要这么改”。这次我用openEuler 22.09搭了一套OpenStack Yoga从裸机到成功创建第一台云主机把部署流程、关键参数和踩过的坑都整理了一遍。如果你手里也有一台服务器想体验从操作系统到上云的全过程这篇文章可以直接照着走。我默认你至少熟悉Linux基础命令、会看日志、会用vi改配置但不要求你把OpenStack组件倒背如流。文章重点放在怎么选用、为什么这样配置、出问题从哪查不会给你堆一堆命令然后说“执行即可”。1. 为什么选openEuler 22.09 OpenStack Yoga这个组合1.1 openEuler 22.09适不适合作云平台底座先说结论适合做测试环境和开发环境生产环境需要自己再跑一轮验证。openEuler 22.09这个版本吸引我的地方主要有三点内核版本够新、Python 3环境完整、软件仓库里云平台相关依赖比较齐全。很多人在部署OpenStack时遇到的第一类问题不是OpenStack本身而是底层发行版的Python环境和依赖库不干净。Yoga版本要求Python 3.6以上一些老系统默认还是Python 2.x几乎是装到一半就会冒出各种“找不到模块”的错误。openEuler 22.09默认Python版本满足要求编译工具链、开发库也都是现成的省掉了不少折腾时间。另一点是内核。云平台底层的KVM虚拟化、Open vSwitch网桥、网络命名空间这些能力都依赖内核支持。openEuler 22.09的内核版本对应功能和兼容性都不错模块加载正常部署过程中很少遇到“内核能力缺失”这种令人头大的问题。我这里要特意提醒一句不是系统越新越好。搭建云平台和日常升级操作系统完全是两回事。我见过一些人先把系统升到最新再开始装OpenStack结果组件之间的兼容性变得不可控。我的建议是选一个明确版本之后部署期间不要做大版本升级保持环境行为可预期。云平台是基础软件它下面的操作系统必须“稳”而不是“最新”。1.2 Yoga不是最新版但它是现阶段很稳的选择OpenStack每年发布两个版本Yoga对应2022.1这个版本代号。它属于整个组件体系已经比较成熟的阶段没有伤筋动骨的重构很多服务之间的版本约束关系已经固定下来。举个直观例子Yoga时期Keystone、Nova、Neutron这些核心服务的版本号社区里能查到的部署案例非常多。你遇到问题去搜很容易找到相似的报错场景和解决方案。反过来如果追最新版本社区里踩坑的人还不够多问题沉淀不充分排错反而困难。还有一点是Packstack这类部署工具对Yoga的支持已经非常完善。Packstack通过Puppet模块去编排OpenStack服务它对版本敏感Yoga正好是它支持很成熟的版本区间。如果你选择一个太新的OpenStack版本部署工具可能还没完全适配错误会变得很不可控。所以我选Yoga的核心逻辑就一句话在稳定和功能之间取平衡优先保证能顺利部署、能顺利用起来。1.3 部署方式怎么选才不劝退OpenStack部署方式大致有三类自动化装配工具部署比如Packstack一条命令把控制节点、网络节点、计算节点全部装配好。手动逐组件部署按官方文档手动配置Keystone、Glance、Nova、Neutron等。容器化/云原生部署把OpenStack服务放进容器运行底层再加一层抽象。单节点学习环境我直接推荐第一种。它的价值在于先让你看到“一台完整的OpenStack应该长什么样”把服务之间的关系建立起来。之后即使要手动部署也有一个参照物。如果一上来就手动装十几个服务很可能还没看到云主机就放弃了。容器化部署听起来炫酷但排障时你会多一层容器网络的复杂度对于理解OpenStack本身这件事帮助有限。另外提一句Packstack生成的All-in-one环境虽然不适合生产但非常适合做POC验证、功能测试和二次开发的起步环境。这篇文章后面所有操作都基于这个选择。2. 开工前先把环境底子打牢这里最容易被返工2.1 硬件需求与节点角色怎么规划硬件上我先给一个可运行的最低配置再给一个建议配置项目最低要求建议配置CPU4核支持硬件虚拟化8核或以上内存8GB16GB系统盘100GBSSD 240GB及以上网卡至少1块2块及以上一个管理网一个业务网为什么内存建议16GB因为单节点All-in-one环境里Controller、Network、Compute角色全挤在一台机器上。控制面组件非常多比如Keystone、Nova API、Neutron server、Glance、Horizon、数据库、消息队列再加上nova-compute和若干云主机实例8GB会显得非常捉襟见肘。网络规划上最少需要两块网卡一块用于管理网API通信、SSH、数据库同步另一块用于业务网云主机外部访问和浮动IP。如果只有一块网卡技术上能用VLAN子接口代替但配置复杂度和排障难度都会上升。我的建议是别在这一步省。2.2 主机名、hosts、时间同步一个都不能省安装系统之后第一件事是设置主机名并且把本机IP和主机名的映射写进/etc/hosts。OpenStack内部组件之间大量通过主机名互相访问如果主机名解析不到后面会出现各种各样稀奇古怪的“Connection refused”。hostnamectl set-hostname controller.lab.local echo 192.168.122.10 controller.lab.local /etc/hosts时间同步是另一个很容易被忽略的点。Keystone在生成和校验token时会依赖系统时间如果节点时间偏差太大用户会看到“用户名密码正确但就是认证失败”的诡异问题。用chrony做时间同步dnf install -y chrony systemctl enable --now chronyd chronyc sources -v我甚至建议在部署之前先跑一次date确认时间合理再执行安装。这一步花不了30秒却能省下后面好几个小时的排错时间。2.3 防火墙、SELinux、NetworkManager到底要不要关单节点测试环境我建议直接关闭firewalld和SELinux。这是最省事也最不容易出错的做法。systemctl disable --now firewalld setenforce 0 sed -i s/^SELINUX.*/SELINUXpermissive/ /etc/selinux/config为什么先关掉因为Packstack在部署过程中要动态创建网络命名空间、改iptables规则、创建OVS网桥、启动一堆服务。firewalld和SELinux的默认策略很可能拦截这些操作导致服务起来了但网络不通、或组件间无法互信。等学会怎么精确放行之后再考虑在生产环境里逐个打开那完全是另一个话题。NetworkManager的情况更隐蔽。Open vSwitch在接管物理网卡时NetworkManager会大概率过来抢控制权。具体表现是OVS网桥创建成功了但物理网卡起不来或者IP地址冲突。提前排除物理网卡nmcli device set eth1 managed no另外还要开启内核IPv4转发因为云主机的南北向流量要经过节点转发echo net.ipv4.ip_forward1 /etc/sysctl.conf sysctl -p2.4 软件仓库和基础工具准备openEuler有自己的官方软件源同时社区里也有对应的OpenStack软件仓库。先确认基础仓库能正常访问dnf repolist dnf update -y安装一些基础工具避免后面到处找包dnf install -y vim wget git bash-completion同时确认虚拟化相关的内核模块已经加载lsmod | grep kvm如果没有输出先检查BIOS里是否开启了CPU硬件虚拟化。这个检查必须做因为nova-compute启动后找不到KVM云主机是起不来的。3. Packstack跑通单节点全栈的完整流程3.1 安装Packstack部署工具仓库配置没问题之后直接安装dnf install -y openstack-packstackPackstack本质上是一组Puppet模块的封装。它负责把OpenStack十几个服务编排起来自动生成配置、创建数据库、启动服务。它的依赖很多安装时会拉下来一堆包这是正常的耐心等即可。安装完确认一下which packstack能输出版本号就说明这一步通了。3.2 生成并修改应答文件关键参数逐个说Packstack支持直接--allinone一把梭但我强烈建议先生成应答文件检查一遍再执行。应答文件里包含了整个部署过程的全部参数相当于施工图。packstack --allinone --gen-answer-fileanswers.txt打开answers.txt重点看以下几项参数含义建议值CONFIG_CONTROLLER_HOST控制节点IP本机管理网IPCONFIG_COMPUTE_HOSTS计算节点IP列表单节点填本机IPCONFIG_NETWORK_HOSTS网络节点IP列表单节点填本机IPCONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS物理网络到网桥的映射physnet1:br-exCONFIG_NEUTRON_OVS_BRIDGE_INTERFACES网桥绑定的物理网卡br-ex:eth1CONFIG_SWIFT_INSTALL是否安装对象存储不需要就填nCONFIG_HEAT_INSTALL是否安装编排服务按需求填nCONFIG_KEYSTONE_ADMIN_PWKeystone管理员密码设置复杂密码CONFIG_PROVISION_DEMO是否预置演示网络建议填nCONFIG_NEUTRON_OVS_BRIDGE_INTERFACES这一项非常关键。它决定了外部网络那块桥接网卡是哪一块。如果填错了后面把物理网卡从系统网络里摘出来时就会误伤管理网络。我的建议是先ip addr show确认网卡编号再填进答案文件。CONFIG_PROVISION_DEMO默认是y它会自动生成一个demo网络和demo路由。对学习来说是好事但对后续想自己从头创建网络的读者来说预置的demo环境可能会造成认知干扰。我建议填n自己手动创建网络。3.3 执行部署等它跑完然后验证修改完答案文件后执行packstack --answer-fileanswers.txt部署过程大约20到30分钟视网络速度和机器性能而定。这期间屏幕会滚动大量Puppet模块日志看起来像“卡住了”但大多数时候它只是在跑某个模块。**千万不要因为看半天没反应就CtrlC中断。**如果真的中断了重跑同一个答案文件可能续装但更保险的做法是清理干净再重来。如果看到*** Installation completed successfully ***恭喜核心部署已经完成。安装完成后系统会提示管理员凭证文件路径/root/keystonerc_admin先做一轮基础验证确保不是物理装好但服务残废source /root/keystonerc_admin openstack service list openstack endpoint list nova service-list neutron agent-list这些命令分别检查服务注册、访问端点、计算服务状态、网络代理状态。如果某个服务列表里出现down务必先解决再继续不然后面创建云主机必然有问题。3.4 部署后要补的几个检查部署成功不等于一切正常。我还会追加几个检查openstack hypervisor list openstack network agent list openstack compute service listhypervisor里能看到计算节点是否正常上报资源。如果这里为空说明nova-compute有问题后面的云主机全部会创建失败。日志方面Packstack的安装日志存放在/var/log/packstack/目录下里面有个openstack-setup.log。如果部署过程出错先看这个日志的尾部比盲目猜原因有效得多。各组件自己的日志则在/var/log/下对应的子目录里比如/var/log/nova/、/var/log/neutron/。4. 从命令行到控制台创建第一台云主机4.1 加载管理员环境每次操作前先加载管理员的OpenStack环境变量source /root/keystonerc_admin这个文件里定义了所有OpenStack客户端命令需要的环境变量包括OS_AUTH_URL、OS_USERNAME、OS_PASSWORD等。缺了它任何openstack命令都会报认证失败。我习惯把它复制一份加个密码权限管理cp /root/keystonerc_admin /root/adminrc chmod 600 /root/adminrc以后登录后只需要source /root/adminrc。4.2 外部网络和内部网络分开建OpenStack里的网络类型非常多但单节点实验环境最核心的是两种一是外部网络。它对应物理网络网段用于给云主机分配浮动IP让云主机能访问外部网络。创建方式openstack network create external --external --provider-network-type flat --provider-physical-network physnet1 openstack subnet create external_subnet --network external --subnet-range 192.168.1.0/24 --allocation-pool start192.168.1.100,end192.168.1.200 --gateway 192.168.1.1 --no-dhcp注意这里--no-dhcp因为外部网络一般不承担DHCP功能。它只是一个“出入口”不是云主机所在的网段。二是内部网络。云主机的固定IP在这个网段里启用了DHCPopenstack network create internal openstack subnet create internal_subnet --network internal --subnet-range 10.10.10.0/24 --dns-nameserver 8.8.8.8 --gateway 10.10.10.1两个网络之间要通过路由器打通openstack router create vrouter openstack router set vrouter --external-gateway external openstack router add subnet vrouter internal_subnet这样云主机就能通过内部IP互访同时通过浮动IP对外通信。4.3 上传Cirros镜像创建规格、密钥和安全组镜像我推荐使用Cirros体积小、启动快专门用于OpenStack测试。上传命令openstack image create cirros --file /root/cirros.qcow2 --disk-format qcow2 --container-format bare --public创建一个小规格openstack flavor create m1.tiny --ram 512 --disk 1 --vcpus 1云主机登录需要密钥对openstack keypair create lab-key lab-key.pem chmod 600 lab-key.pem安全组必须放行ICMP和SSH否则后面测试时云主机看起来是通的但死活ping不通、连不上openstack security group list openstack security group rule create default --protocol icmp --ingress openstack security group rule create default --protocol tcp --dst-port 22 --ingress这步常被忽略但它是“部署很成功云主机却无法访问”的第一大原因。4.4 启动云主机、绑定浮动IP、验证访问一切准备就绪启动实例openstack server create test-vm --flavor m1.tiny --image cirros --network internal --security-group default --key-name lab-key等到状态变成ACTIVEopenstack server show test-vm创建浮动IP并绑定openstack floating ip create external openstack server add floating ip test-vm 浮动IP测试连通性ping 浮动IP ssh -i lab-key.pem cirros浮动IPCirros的默认用户是cirros不是root。这个细节也要记住。如果这一步通了说明你的OpenStack环境已经具备实际使用能力镜像上传、网络创建、路由器转发、安全组过滤、密钥认证、浮动IP这一整条链路都正常。这也是判断一次部署是否成功的最终标准。5. 部署过程中最值得记录的三个坑5.1 软件仓库里的Packstack和Yoga依赖冲突我在部署时遇到的第一类报错是安装openstack-packstack时出现依赖不满足比如某个python3-openstacksdk包的版本和仓库已有的版本冲突。排查思路分三步dnf repolist dnf update -y dnf install -y openstack-packstack大部分时候是因为仓库元数据已经过期更新索引之后就能解决。如果更新完仍然报依赖问题就需要检查是否同时启用了多个相互冲突的软件源保留一个即可。这里我有一个建议部署前先把所有需要的RPM包下载缓存到本机之后真正执行部署时不需要再访问外部仓库。这样做的好处是提高部署稳定性也避免安装到一半某个包被更新导致版本错乱。命令参考dnf install --downloadonly --downloaddir/root/packages openstack-packstack5.2 OVS网桥绑定物理网卡失败另一个典型问题是部署时ovs-vsctl add-port br-ex eth1失败或者br-ex网桥创建出来了但端口状态一直是DOWN。原因一般是两个物理网卡被NetworkManager管理导致OVS没法正确接管。物理网卡上残留原来的IP地址和网桥IP冲突。解决办法nmcli device set eth1 managed no ip addr flush dev eth1然后再手动验证OVS状态ovs-vsctl show正常情况下br-ex应该存在并且eth1作为端口挂在br-ex下端口状态为UP。这里提醒一句操作前一定要确认eth1是业务网卡不是管理网卡。如果你把管理网卡停用了SSH会立刻断开那就只能去机房了。5.3 云主机创建成功但一直获取不到IP这个坑应该能排进OpenStack新手问题前三名。云主机能创建状态也是ACTIVE但进系统一看网卡没有IP。排查顺序我建议这样看子网有没有开DHCPopenstack subnet show internal_subnet确认enable_dhcp为True。看DHCP agent是否正常运行openstack network agent list如果dhcp-agent不是UP重启服务systemctl restart neutron-dhcp-agent看计算节点上的nova-compute日志tail -n 100 /var/log/nova/nova-compute.log这套排查逻辑对后续多节点部署同样适用。网络问题永远是OpenStack排障的大头把DHCP、Metadata、安全组这三件事理清楚能解决大部分云主机“起不来”的问题。6. 单节点跑通之后怎么继续往前走6.1 理解Packstack生成的配置布局成功部署之后要把安装产物看明白而不是只会用。Packstack生成的所有配置都在/etc/目录下对应的组件子目录里/etc/keystone/认证服务的配置和凭证文件/etc/nova/计算服务配置/etc/neutron/网络服务配置/etc/glance/镜像服务配置/etc/cinder/块存储服务配置数据库则默认在/etc/my.cnf.d/配置下。消息队列服务也装在同一台机器上。理解这个结构后续做配置变更时才知道该去哪个目录改。6.2 从单节点到多节点的最小改动路径Packstack的好处是它可以复用同一个答案文件把计算节点单独指定到别的机器上。操作方法大致是准备一台新的计算节点安装好操作系统配置好软件源、关闭防火墙和SELinux然后重新生成答案文件将CONFIG_COMPUTE_HOSTS改为新节点IP再执行packstack。但这里要坦白讲单节点上已经产生的数据不会自动迁移到新节点。更稳妥的做法是从一开始就按多节点规划。控制节点单独一台计算节点一台网络角色要么放控制器要么独立成网络节点。All-in-one环境适合学习和验证不适合直接当作生产环境长期跑。如果你已经有生产计划建议尽早拆开角色。6.3 备份、升级和日常维护的几个习惯部署者最常见的错误是装完就完事不做任何运维规划。下面几个习惯值得坚持每天或每次变更前备份数据库。OpenStack大量状态都在数据库里比如实例记录、网络状态。配置文件改动前先复制一份.bak。很多问题都是“改了一个参数没记下来事后不知道改了什么”。使用openstack-service这一个命令来查看和管理服务状态openstack-service status openstack-service restart这条命令会自动识别本机OpenStack所有相关服务比手动一个个systemctl高效得多。升级任何组件前做虚拟机快照。特别在网络和计算核心组件上宁可多花五分钟做快照也不要在没有回退手段的情况下升级。最后再分享一个小习惯部署成功那一刻我会把nova service-list、neutron agent-list、openstack endpoint list三个命令的正常输出保存一份作为这个环境的状态基线。之后任何一次改动或排障都先拿当前状态和这份基线对比。差异在哪问题基本就在哪。这个习惯帮我省了大量重复排查时间也推荐给你。